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ABSTRACT 


The  speed  and  efficaey  with  which  front-line  warfighters  in  stressful  conditions  can 
submit  resource  requests,  such  as  a  casualty  evacuation,  could  mean  the  difference 
between  life  and  death.  Traditional  methods  to  call  for  resources  require  training,  are 
error-prone  and  can  be  sluggish.  The  Handheld  Emergency  Logistics  Program  (HELP) 
was  developed  by  the  authors  of  this  thesis  to  assist  both  trained  and  untrained  persons  in 
requesting  resources  from  supporting  agencies.  HELP  was  developed  to  prove  the 
concept  that  off-the-shelf  mobile  technology  can  significantly  improve  the  speed  and 
efficacy  of  resource  requests. 

This  thesis  aims  to  allow  HELP  to  exploit  built-in  sensors  in  modern  commercial 
off-the-shelf  handheld  smart  devices  and  their  computation  and  communication 
capability  to  reduce  the  chance  of  error,  reduce  the  need  to  pull  information  from 
memory,  reduce  manual  data  entry,  and  provide  multiple  redundant  modalities  for 
performing  the  same  action. 

Our  findings  indicate  that  with  the  assistance  of  HELP,  users  submitting  resource 
requests  committed  half  as  many  errors  and  completed  the  request  in  half  the  amount  of 
time  as  compared  to  a  control  group  using  traditional  methods.  We  recommend  that  the 
concept  of  using  smart  devices  to  call  for  resources  be  further  developed  into  a  program 
of  record. 
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I.  INTRODUCTION 


A.  MOTIVATION 

The  authors  recently  returned  from  combat  deployments  prior  to  arrival  at  the 
Naval  Postgraduate  School.  On  several  occasions  during  deployment,  we  were  required 
to  call  for  support  from  higher  headquarters.  One  of  the  most  important  items  on  our  pre¬ 
combat  checklists  was  the  “smart  pack”  of  request  formats.  A  “smart  pack”  is  a  compact 
booklet  full  of  laminated  sheets  that  contains  request  formats  for  anything  from  casualty 
evacuations  to  explosive  ordnance  disposal  support. 

Resource  requests  are  typically  specifically  formatted  to  give  the  supporting 
agency  all  of  the  information  required  to  provide  assistance  to  the  requestor.  Most 
resource  requests  require  the  requestor  to  provide  common  information,  such  as  location, 
contact  information,  and  unit  information.  All  requests  also  require  information  specific 
to  the  type  of  request  (e.g.,  casualty  information,  pickup  location).  Typically,  these 
requests  are  made  during  times  of  stress.  For  example,  a  Marine  requesting  evacuation  of 
a  casualty  is  likely  under  fire  and  possibly  assisting  with  treatment  and  triage  procedures. 

Our  deployments  were  in  different  places  with  different  missions,  but  we  both 
independently  recognized  that  there  had  to  be  a  better  way  to  call  for  support.  During  an 
after  action  review  (AAR)  from  a  mission  that  required  a  casualty  to  be  evacuated,  we 
discussed  how  the  call  for  evacuation  was  very  time  consuming  and  added  a  great  deal  of 
stress  to  an  already  stressful  situation.  When  discussing  what  was  eventually  a  successful 
casualty  evacuation,  one  of  the  Marines  in  the  AAR  joked,  “Shouldn’t  there  be  an  app  for 
that?”  He  posed  a  very  legitimate  question.  Why  in  the  age  of  near-instant 
communication  are  warfighters  still  lugging  around  large  notebooks,  formulating 
resource  requests  by  hand,  only  then  to  transmit  the  requests  over  a  voice  radio? 

B,  PROBLEM  STATEMENT 

There  currently  exists  no  mobile  application  that  runs  on  multiple  devices  to  assist 
a  front  line  warfighter  to  call  for  logistics  resources.  In  the  current  military  process,  one’s 

ability  to  call  for  assistance  is  often  challenged  by  several  factors: 
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•  Training.  A  warfighter  must  receive  initial  and  sustainment  training  using 
the  prescribed  formats  in  order  to  efficiently  and  effectively  request 
resources. 

•  Human  Errors.  Irrespective  of  the  level  of  training,  resource  requests  are 
prone  to  errors  both  in  formulation  and  during  voice  transmission. 

•  Time.  Manually  formulating  the  request  and  submitting  the  request  to 
higher  headquarters  takes  a  considerable  amount  of  time.  Often,  when 
requests  for  assistance  are  made,  time  is  usually  limited  and  wasted 
seconds  can  be  catastrophic. 

•  Stress.  When  calling  for  assistance,  the  conditions  are  rarely  ideal  and 
compound  the  previous  three  factors. 

We  propose  to  address  this  problem  through  the  development  of  HELP;  Handheld 
Emergency  Logistics  Program,  an  application  suite  that  can  exploit  embedded 
smartphone  functionality  to  assist  the  warfighter  [1].  Smartphones  have  a  great  deal  of 
computational  power,  many  built-in  sensors  and  communication  capability  that  can  be 
used  to  alleviate  many  of  the  problems  associated  with  resource  requests.  We  will 
leverage  the  technology  in  the  devices  to: 

•  Provide  a  simple,  common  user  interface.  This  will  limit  the  required 
training,  decrease  human  errors,  and  decrease  overall  transmission  time. 

•  Use  device  sensors  when  possible  in  order  to  alleviate  human  errors  and  to 
make  the  process  faster. 

•  Use  the  devices’  inherent  digital  communication  capability  in  order  to 
speed  up  transmission. 

•  Provide  visual  and  tactile  feedback  in  order  to  assist  the  user  as  much  as 
possible  during  stressful  situations. 

Our  hypothesis  is  that  the  use  of  a  well-developed  application  suite  to  replace 
traditional  resource  request  methods  will  result  in  a  significant  decrease  in  errors  and  the 
overall  time  required  to  make  resource  requests  [1]. 

C.  RESEARCH  QUESTIONS 

Primary  Research  Question:  What  is  a  suitable  software  architecture  for  a 
commercial  off-the-shelf  (COTS)  handheld  system  to  assist  an  untrained  Marine  or 
Soldier  call  for  resources? 
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Secondary  research  questions: 

•  Which  sensing  modalities  of  current  COTS  mobile  devices  can  be  used  to 
facilitate  rapid  request  generation? 

•  What  measures  can  be  taken  to  prevent  errors  in  the  generation  of  call  for 
resources? 

•  What  measures  can  be  taken  to  make  the  application  usable  in  stressful 
environments? 

•  What  are  the  time  and  accuracy  benefits  to  using  a  handheld  device 
compared  with  traditional  methods? 

•  Can  an  untrained  Marine  or  Soldier  use  the  device  with  little  or  no  prior 
training? 

•  What  are  the  security  concerns  when  dealing  with  individual  mobile 
devices? 

D,  SCOPE  AND  LIMITATIONS 

This  work  is  inspired  by  a  request  from  the  United  States  Marine  Corps 
Installations  and  Logistics  Command.  They  seek  to  leverage  current  commercial 
technology  to  assist  with  calls  for  resources.  This  is  based  upon  experience  and  after¬ 
action  reports  from  many  units  returning  from  deployments. 

Our  research  has  been  conducted  in  several  phases: 

•  Research  the  current  table  of  equipment  for  USMC  infantry  companies. 

•  Research  training  and  readiness  standards  for  company  level  leadership. 

•  Develop  an  architecture  for  a  new  COTS  device-based  systems 

•  Design,  develop,  and  test  select  resource  request  applications 

•  Resolution  of  issues 

•  Command  post  exercise  (CPX)  aboard  Naval  Postgraduate  School 

•  Refinement  of  application/architecture  resultant  from  CPX 

•  Field  testing  of  our  system  in  a  scenario-driven  exercise  utilizing  live 
assets 

It  is  not  within  the  scope  of  this  thesis  to  begin  any  security  certification  and 
accreditation  efforts. 
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E,  METHODOLOGY 

We  began  our  research  by  reviewing  the  current  digital  communications 
capability  available  at  a  line  infantry  company.  We  then  built  a  test  and  evaluation 
network  at  Naval  Postgraduate  School  that  was  configured  as  a  company  combat 
operations  center  (COC)  using  the  available  equipment  set. 

Upon  completion  of  the  test  network,  we  designed  and  created  a  native 
application  on  an  Android  device. 

Upon  completion  of  the  application,  we  tested  the  connectivity  and  validated  the 
desired  capability. 

After  proper  implementation  of  the  application,  we  researched  the  training 
required  to  familiarize  users  with  the  application. 

As  a  final  proof  of  concept,  we  arranged  to  test  the  application  suite  with  students 
awaiting  training  at  the  USMC  Marine  Detachment  at  the  Defense  Language  Institute. 

F.  THESIS  ORGANIZATION 

Chapter  I  discusses  the  purpose  of  the  HELP  suite  of  applications  and  why  there 
is  a  need  for  this  type  of  system. 

Chapter  II  discusses  the  background  of  digital  resource  request  formats  as  well  as 
an  in-depth  history  of  medical  evacuations,  explosive  ordnance  disposal  and  logistics 
requests.  This  provides  some  background  on  the  importance  of  request  structure  and 
demonstrates  the  complexity  of  some  of  the  formats. 

Chapter  III  discusses  the  design  and  development  of  the  HELP  suite  of 
applications.  We  outline  the  applications’  design  and  functionality  and  document  the 
screen-by-screen  usage  and  user- interface  (UI). 

Chapter  IV  outlines  the  testing  and  evaluation  of  the  prototype  suite  of 
applications. 
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Chapter  V  presents  the  conclusions  of  our  study  and  makes  recommendations  for 
future  work.  The  HELP  suite  source  code  can  be  used  as  a  shell  for  a  variety  of  different 
resource  requests. 
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II.  BACKGROUND 


Handheld  digital  devices  are  fairly  common  throughout  the  military.  In  our 
experience,  such  devices  have  one  commonality:  these  digital  devices  perform  a  single 
task.  For  example,  in  2002,  the  Artillery  community  was  given  a  digital  device  called 
“Pocket-Sized  Forward  Entry  Device”  (PFED)  to  call  for  artillery  fires.  The  device  was 
built  around  a  modified  Palm  device  and  could  perform  the  single  task  of  calling  for 
artillery  fires.  A  few  years  later,  the  Artillery  community  was  then  given  a  different 
Palm-based  device  (Centaur)  to  compute  firing  data.  Again,  the  hardware  could  perform  a 
single  task:  computing  firing  data.  The  Infantry  community  has  had  different  iterations  of 
a  handheld  computer  to  compute  firing  data  called  the  Mortar  Ballistic  Computer  (MBC). 
This  device  also  performed  a  single  task:  computing  firing  data. 

Hardware  development  has  a  significant  cost  associated  with  the  end-item 
deployment,  as  these  systems  are  typically  built  from  scratch  or  modified  from  existing 
technology  [2].  Our  research  focus  has  been  to  use  existing  commercially  available 
hardware  and  aggressively  use  the  capabilities  inherent  in  these  devices  to  maximize 
efficiency.  COTS  smart  devices  are  very  common  and  provide  an  enormous  capability  in 
terms  of  functionality,  communications  capability  and  computing  power. 

During  any  combat  mission,  there  will  be  a  need  to  request  resources  and  support 
from  supporting  headquarters.  A  small  unit  (team,  squad,  or  platoon)  only  has  a  finite 
amount  of  organic  or  local  capability.  Requests  for  specialized  support  are  currently 
transmitted  and  coordinated  via  radio  to  the  unit’s  supporting  headquarters.  Our  research 
goal  is  to  provide  a  better  way  for  front-line  units  to  transmit  these  requests  using 
commercial  devices.  As  a  baseline  proof  of  concept  for  using  a  smart  device  to  transmit 
requests,  we  chose  three  common  requests:  casualty  evacuation  (CASEVAC),  explosive 
ordnance  disposal  (EOD)  and  rapid  logistics  request. 

A,  CASUALTY  EVACUATIONS 

Casualties  have  always  been  a  part  of  warfare  and  often  a  part  of  significant 
natural  or  man-made  disasters.  Until  recently,  the  care  of  casualties  was  primitive  at  best 
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and  many  perished  through  a  laek  of  understanding  of  medieine  and  hygiene.  To 
eomplieate  matters,  many  of  the  wounded  lay  on  the  battlefield  for  days  (and  in  some 
eases  weeks)  before  they  were  taken  to  a  field  hospital.  Undoubtedly,  many  individuals 
died  from  untreated  wounds  while  lying  awaiting  treatment.  Over  the  last  500  years,  for 
every  soldier  killed  in  battle,  there  has  been  an  average  of  4  wounded  during  the  battle 
[3].  In  addition,  of  those  wounded,  approximately  one-third  of  those  soldiers  needed 
serious  medieal  treatment  for  their  injuries  [3]. 

It  was  not  until  the  Civil  War  that  the  United  States  developed  a  formal  means  of 
evaeuating  the  wounded  off  the  battlefield  [3].  Dr.  Jonathan  Letterman  ereated  a  system 
for  the  Army  of  the  Potomae  to  effieiently  and  effeetively  evaeuate  the  wounded.  He 
instituted  the  use  of  triage,  ambulanees,  and  field  hospitals.  These  eontributions  helped 
earned  him  the  title  of  “Father  of  Modern  Battlefield  Medieine”  [4].  The  praetiees  that  he 
instituted  helped  drive  down  the  20+%  hospital  mortality  rate  at  the  start  on  the  war  down 
to  10%  by  the  time  of  Gettysburg  [3].  The  military  eontinued  to  improve  on  the  basie 
prineiples  of  battle  evaeuation  that  were  introdueed  in  the  Civil  War.  The  military 
leveraged  teehnology  and  advaneements  in  medieal  teehnology  to  eontinue  to  deerease 
the  mortality  rate  of  soldiers  on  the  battlefield  even  as  the  lethality  of  weaponry 
inereased.  Many  lessons  were  learned  the  hard  way  from  World  War  II  through  the 
Vietnam  eonfiiet,  from  the  importanee  of  treating  for  shook  to  leveraging  helioopters  to 
evaeuate  the  wounded.  However,  these  lessons  paid  off  and  during  the  World  War  II, 
Korean,  and  Vietnam  wars  the  hospital  mortality  rate  was  between  2.4  and  2.6  peroent 
[3]. 

While  the  basios  of  rapid  evaeuation  from  the  battlefield  is  no  different  today  than 
in  the  past,  we  have  past  suooesses  and  failures  from  whioh  to  draw  experienoe  [3].  One 
of  the  key  lessons  learned  from  past  oonfliots  was  the  importanee  of  the  “Golden  Hour.” 
The  “Golden  Hour”  is  the  eoneept  that  if  a  severely  wounded  soldier  reeeives  “surgery  or 
advaneed  trauma  life  support”  within  the  first  hour  he  injured,  his  ehanees  of  survival  are 
dramatieally  inereased  [5].  The  past  and  present  data  from  Operation  Iraqi  Freedom  and 
Operation  Enduring  Freedom  provides  surprising  statistieal  information  on  how 
important  the  “Golden  Hour”  truly  is.  The  data  shows  that  “90  peroent  of  all  oasualties 
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die  within  the  first  hour  of  severe  wounding  without  advanced  trauma  life  support... 
[and]  67  percent  die  within  the  first  30  minutes”  [5].  Studies  have  shown  that  injured 
soldiers  receiving  medical  care  within  the  first  hour  have  the  greatest  chance  of  survival 
and  every  minute  after  that  hour  their  odds  decrease  significantly  [5].  What  these  studies 
show  is  that  time  is  of  critical  importance  in  treating  a  wounded  soldier.  Fortunately, 
today’s  military  members  can  rely  on  a  robust  and  efficient  evacuation  system  for 
casualties  sustained  on  the  battlefield  [3],  [5]. 

B,  EXPLOSIVE  ORDNANCE  DISPOSAL 

During  the  two  recent  major  conflicts,  Improvised  Explosive  Devices  (lEDs)  have 
become  the  preferred  weapon  of  choice  for  insurgents  to  attack  coalition  forces.  These 
devices  can  easily  be  made  out  of  common  everyday  materials.  It  has  become  a  constant 
struggle  between  coalition  forces  and  insurgents.  The  insurgents  make  the  devices  harder 
to  detect  and  coalition  forces  leverage  technology  and  tactics  to  find  lEDs  before  they  can 
cause  damage.  Currently,  coalition  forces  are  winning  the  battle  because  they  are 
discovering  over  78%  of  lEDs  before  they  detonate  [6].  While  discovering  an  lED  is  a 
small  victory,  the  devices  must  be  rendered  safe  by  Explosive  Ordnance  Disposal  (EOD). 
Because  of  the  limited  number  of  EOD  teams,  units  must  request  their  support  through  a 
standardized  format  for  a  team  to  come  to  the  site  of  the  lED  for  neutralization. 

C.  RAPID  LOGISTICS  REQUEST 

Most  battalion  and  higher  level  units  develop  a  format  for  generic  logistics 
requests  and  define  the  format  in  their  unit  standard  operating  procedures  (SOPs).  There 
are  currently  no  Marine  Corps  standard  formats  for  requesting  logistics  support,  but  most 
examples  we  researched  had  common  elements.  A  rapid  request  format  would  typically 
include  options  for: 

•  Maintenance  Contact 

•  Vehicle  Recovery 

•  Resupply 

•  Troop/Cargo  Movement 

•  Engineering  Support 
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D,  STRESSES  IN  COMBAT  AND  THE  NEED  FOR  TAILORED 

INTERFACES 

Stress  is  best  described  as  interaction  between  three  elements.  “These  elements 
consist  of  perceived  demand,  perceived  ability  to  cope,  and  finally  the  perception  of  the 
ability  to  cope  with  the  demand”  [7].  It  is  well  known  that  combat  is  stressful.  However, 
the  level  of  stress  and  how  stress  physically  and  mentally  affects  the  solider  has  only 
been  scientifically  studied  over  the  last  60  years.  Even  with  the  best  study,  the  conditions 
of  combat  can  never  fully  be  tested  in  an  experiment  or  lab  environment.  Nevertheless 
the  scientific  experiments  are  able  to  shed  light  on  what  individuals  face  in  combat  and 
how  soldiers  react  to  the  stresses  of  combat. 

These  studies  have  not  found  anything  groundbreaking,  as  it  is  well  known  that 
stress  decreases  judgment  and  increases  reaction  time.  The  studies  have  been  able  to 
quantify  how  much  stress  affects  humans  both  physically  and  mentally.  Up  to  80%  of 
individuals  in  a  stressful  situations  experience  what  is  known  as  the  tunneling  effect  or 
tunnel  vision  [8].  This  effect  makes  the  surrounding  environment  seem  smaller  and  they 
are  unable  to  process  all  of  the  stimulation  for  the  environment.  Next,  over  80%  of 
individuals  have  experienced  time  distortion  whether  it  is  slowing  down  or  speeding  up 
[8].  It  has  also  been  shown  that  in  stressful  conditions  there  is  degradation  in  manual 
dexterity  and  fine  motor  skills  [7].  Individuals  lose  their  ability  to  write,  hit  a  small 
button,  or  shake  uncontrollably  regardless  of  how  scared  they  are  [7],  [8].  Furthermore, 
studies  have  shown  that  individuals’  “judgment  in  stressful  situations  is  worse  than  when 
they  are  intoxicated  or  given  powerful  sedatives”  [9].  Additionally,  studies  have  found 
that  factors  like  loud  noise,  sleep  deprivation,  fatigue,  and  poor  nutrition  levels  can 
increase  the  negative  effects  of  stress  on  the  human  body  [7],  [8].  One  thing  in  common 
with  all  of  these  factors  is  that  they  will  all  be  found  in  combat. 

While  the  military  may  not  have  always  quantifiably  understood  what  stress  does 
to  a  soldier,  leaders  have  understood  that  stress  does  affect  every  soldier.  Over  the 
centuries,  militaries  have  learned  that  a  soldier  can  be  inoculated  against  stress  similar  to 
diseases  [10].  This  inoculation  includes  introducing  the  soldier  to  stress  during  training 
[7],  [8],  [10].  This  way  the  soldier  can  experience  working  under  stressful  conditions 
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before  they  experienee  stress  in  eombat.  This  allows  the  soldier’s  body  and  mind  to 
become  stronger  and  more  resistant  to  stress  much  like  an  individual  trains  their  muscles 
in  the  gym  [7].  Recent  studies  have  shown  that  experienced  soldiers  are  more  resistant  to 
the  negative  effects  of  stress  than  soldiers  just  entering  the  military  [7-9].  Furthermore  it 
has  been  shown  through  real-life  situations  and  studies  that  simple  tasks  or  well  learned 
tasks  can  be  completed  and  performed  efficiently  under  stress  [7],  [9],  [10].  This  is  why 
the  unit  leaders  spend  hours  drilling  their  troops  to  perform  simple  tasks  such  as  changing 
magazines  and  reaction  to  contact.  Furthermore,  the  military  has  used  this  information 
when  it  comes  to  designing  interfaces  and  procedures  that  are  used  in  combat.  Some  may 
consider  the  military  to  be  an  expert  in  the  realm  of  designing  systems  for  use  under 
stressful  situations. 

Even  with  the  information  from  the  studies  and  the  knowledge  on  stress,  the 
military  is  facing  challenges  with  today’s  technology.  Due  to  the  fact  that  most  systems 
are  becoming  more  technology-based  and  have  the  ability  to  perform  multiple  functions, 
physical  buttons  and  levers  have  started  to  disappear  from  system  interfaces.  The  classic 
physical  buttons  and  levers  have  disappeared  even  though  they  have  been  proven  in 
studies  to  be  easier  to  find  and  manipulate  under  stress  [11].  Furthermore,  the  military  is 
starting  to  get  more  COTS  products  instead  of  traditional  purpose-built  devices  and 
systems.  While  this  is  not  necessarily  a  bad  thing,  challenges  arise  when  purchasing 
devices  that  were  primarily  designed  for  civilian  use. 

The  primary  challenge  that  COTS  technology  brings  to  the  battlefield  is  how  the 
soldier  interfaces  with  the  system.  Lacking  physical  buttons  or  levers  increases  the 
likelihood  of  mistakes.  Furthermore,  the  more  options  or  modes  the  interface  has,  the 
more  is  the  information  overload  [11],  [12].  Systems  that  are  not  designed  to  be  simple 
and  easy  to  use  run  the  risk  of  failing  the  soldier  in  a  critical  time  of  need.  This  has 
become  more  important  today  because  it  is  believed  that  the  soldier  of  the  future  will 
carry  not  only  his  rifle  into  battle  but  a  smartphone  as  well.  While  undoubtedly 
smartphones,  coupled  with  their  applications,  can  increase  lethality  and  effectiveness  of  a 
soldier,  they  also  have  the  ability  to  become  a  burden.  Their  effectiveness,  or  burden,  on 
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a  soldier  will  be  judged  on  the  ease  with  whieh  the  soldier  is  able  to  interface  with  the 
system  in  a  stressful  situation. 

While  the  technology  industry  has  very  good  knowledge  and  experience  in 
building  interfaces  for  the  normal  user,  it  lags  in  the  development  of  interfaces  for  users 
in  a  stressful  situation  [12],  On  the  other  hand  the  military  has  an  excellent  understanding 
of  stressful  situations  yet  it  lags  behind  in  the  understanding  of  technology.  The 
development  of  a  technology  interface  for  stressful  situations  has  undoubtedly  lagged 
behind  because  of  the  small  number  of  individuals  that  are  affected  and  the  lower 
potential  for  financial  gain.  With  that  being  said,  there  are  some  researchers  who  have 
come  up  with  seven  guidelines  or  as  they  them  “laws”  that  technology  should  adhere  to 
when  being  used  in  a  stressful  situation,  or  what  the  researchers  call  High  Velocity 
Human  Factors  (HVHF).  They  describe  HVHF  as  a  time -pressured,  fast-evolving,  and 
high-stakes  environment  [13].  A  brief  summary  of  the  seven  laws  are  provided  below  and 
a  more  detailed  explanation  for  each  can  be  found  in  Appendix  F: 

1,  Law  of  Relevance 

The  human-machine  interface  (HMI)  should  help  aid  the  user  and  provide  helpful 
cues  when  appropriate  [13]. 

2,  Law  of  Acceptance  [of  Relevance] 

The  HMI  should  not  be  so  overwhelming  that  it  would  contribute  to  the  user 
losing  situation  awareness  [13]. 

3.  Law  of  Transparence 

The  HMI  should  not  prevent  the  user  from  perceiving  information  from  the 
surrounding  environment  [13]. 

4.  Law  of  Clairvoyance 

The  HMI  as  the  ability  to  predict  information  for  the  user  or  provide  information 
before  the  user  is  aware  they  need  it  [13]. 
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5. 


Law  of  Absoluteness 


The  HMI  provides  aceess  to  important  information  or  functions  with  minimal 
buttons  or  key  strokes,  and  can  determine  when  approximations  instead  of  exact  numbers 
are  more  appropriate  [13]. 

6,  Law  of  Intelligence 

The  system  should  resolve  as  many  choices  are  possible  to  eliminate  work  for  the 
user  and  know  the  correct  time  to  ask  the  user  for  inputs  [13]. 

7,  The  Law  of  Reliance 

The  system  does  what  it  is  intended  to  do  with  a  trivial  amount  of  false  positives 
or  negatives  [13]. 

The  seven  laws  described  above  are  great  guidelines  that  should  be  followed 
when  designing  an  interface  for  future  soldiers  on  the  battlefield.  If  these  laws  are 
considered  during  the  design  of  an  application  or  device  there  is  little  doubt  that  the 
device  or  application  will  be  able  to  meet  the  demands  of  a  soldier  on  the  battlefield  in 
the  21st  century.  However,  if  these  laws  are  ignored,  lifesaving  applications  or  devices 
could  be  considered  too  bulky  or  unrealistic  on  the  modem  battlefield  or  worse  they  will 
fail  the  soldier  at  the  most  critical  time. 

E.  MEDICAL/CASUALTY  EVACUATION  FORMAT 

The  widespread  use  of  radios  during  combat  operations  enables  the  front-line 
warfighters  to  request  a  variety  of  support.  In  most  cases,  requests  for  support  have  been 
standardized  to  streamline  processing.  Support  can  range  from  time  sensitive  requests, 
such  as  close  air  support,  to  routine  resupply  requests.  Regardless  of  the  request,  the 
format  is  usually  standardized  across  all  branches  of  the  military  (as  well  as  many  NATO 
allies)  to  ensure  all  relevant  information  is  passed  in  a  timely,  efficient  and  unambiguous 
manner;  medical  evacuations  (MEDEVAC)  or  casualty  evacuation  (CASEVAC)  requests 
are  no  different.  In  the  U.S.  military,  there  are  two  types  of  medical  evacuations.  While 
they  have  slightly  different  meanings,  there  is  a  difference  that  can  confuse  a  layman. 
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Furthermore,  the  individual  requesting  the  medieal  evaeuation  request  only  needs  to 
submit  the  standard  9-Line  format  to  reeeive  support,  beeause  higher  headquarters 
ultimately  determines  whieh  of  the  two  types  of  platform  a  unit  will  reeeive.  The  two 
types  are  CASEVAC  and  MEDEVAC.  CASE  VAC  is  the  use  of  ground  vehieles  or 
aireraft  to  evaeuate  a  easualty;  the  primary  purpose  of  these  vehieles  is  not  medieal 
evaeuation  but  taetieal  support  of  troops  on  the  ground.  Eor  example,  a  CH-53  (primarily 
a  eargo  transport)  might  be  tasked  to  piek-up  an  injured  Marine  and  take  him  to  a  medieal 
treatment  faeility.  A  MEDEVAC  is  performed  by  a  platform  that  has  the  sole  purpose  of 
medieal  evaeuation.  While  there  is  a  differenee  between  CASEVAC  and  MEDEVAC, 
most  individuals  in  the  military  use  the  terms  interehangeably.  Again,  no  matter  whieh 
type  of  evaeuation  platforms  one  reeeives,  the  initial  request  is  the  same  [14]. 

In  order  to  have  a  easualty  evaeuated  off  the  battlefield,  an  individual  must  send  a 
MEDEVAC  request  to  higher  headquarters  elements.  Erom  there,  the  higher  headquarters 
make  the  appropriate  deeisions  on  what  type  of  platform  (ground  or  air)  to  deploy  to 
evaeuate  the  easualty  in  addition  to  whieh  medieal  treatment  faeility  is  most  suitable  to 
deal  with  the  injuries  the  easualty  has  sustained.  Beeause  time  is  eritieal  during  any 
evaeuation,  the  request  sent  to  higher  headquarters  must  eontain  enough  information  to 
make  an  informed  deeision  while  not  wasting  time  transmitting  useless  information. 

The  standard  NATO  MEDEVAC  9-Eine  request  for  all  serviees  is  as  follows: 

Eine  l-Eoeation  of  Piekup  Site 

Eine  2-Radio  Erequeney  and  Call  Sign 

Eine  3-Number  of  Patients  by  Preeedenee 

Eine  4-Speeial  Equipment  Needed 

Eine  5-Number  of  Patients  by  Type 

Eine  6-Seeurity  of  the  Piekup  Site 

Eine  7-Method  of  Marking  for  the  Piekup  Site 

Eine  8-Patients  Nationality  and  Status 

Eine  9-Presenee  of  Nuelear,  Biologieal,  or  Chemieal  Contamination 
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Detailed  descriptions  are  as  follows. 


1,  Line  1:  Location  of  Pickup  Site 

This  line  conveys  the  desired  pickup  location  for  the  patient(s).  This  is  normally 
within  the  proximity  of  the  location  where  the  casualty  was  injured.  However,  based  on 
the  situation,  this  location  could  be  located  several  kilometers  away  from  the  where  the 
injury  was  sustained.  The  on-scene  commander  normally  determines  this  pickup  location; 
however,  depending  on  the  platform  used  for  the  evacuation,  the  pilot  may  alter  the 
pickup  location  because  of  platform  limitations.  The  location  of  the  pickup  site  must  be 
sent  in  one  of  three  formats: 

•  Military  Grid  Reference  System  (MGRS) 

•  Latitude  and  Longitude 

•  A  previously  designated  Landing  Zone  (LZ). 

In  order  to  use  a  landing  zone,  the  unit  requesting  the  MEDEVAC  must  ensure 
that  higher  elements  already  have  the  coordinates  to  that  landing  zone.  When  passed  over 
the  radio,  the  radio  operator  will  announce  “Eine  1”  followed  by  one  of  the  three 
approved  formats.  Eor  example,  “Eine  1-1  lU  GR  123  456”  [14]. 

2.  Line  2:  Radio  Frequency  and  Call  Sign 

This  line  is  used  to  pass  the  radio  frequency  and  call  sign  of  the  unit  requesting 
the  MEDEVAC  so  the  platform  performing  the  evacuation  knows  how  and  whom  to 
contact  on  the  radio.  While  this  is  important  for  any  ground  evacuation,  it  is  extremely 
important  for  air  evacuation.  This  information  allows  the  helicopter  to  talk  to  the  unit  on 
the  ground  to  receive  terminal  control  before  landing.  In  addition,  this  information  is 
passed  so  that  the  higher  elements  that  initially  receive  the  request  can  reestablish 
communication  if  something  happens  during  the  transmission  of  the  initial  request.  When 
passed  over  the  radio,  the  radio  operator  will  announce  “Eine  2”  followed  by  the  radio 
frequency  and  call  sign.  Eor  example,  “Eine  2-E123,  Wolverines”  [14]. 
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3,  Line  3:  Number  of  Patients  by  Precedence 

This  line  is  used  to  eonvey  the  number  of  patients  that  need  to  be  evaeuated  and 
indieate  how  serious  their  injuries  are.  There  are  five  different  preeedence  levels  that  ean 
be  assigned  to  a  casualty:  urgent,  urgent  surgical,  priority,  routine,  and  convenience.  Each 
level  has  an  associated  letter  assigned  to  it.  Letter  “A”  is  assigned  to  urgent,  “B”  to  urgent 
surgical,  “C”  to  priority,  “D”  to  routine,  and  “E”  to  convenience.  The  letters  are  used  in 
place  on  saying  the  level  over  the  radio  to  help  speed  up  transmission  and  reduce  errors. 
The  senior  medical  individual  on  the  scene  (typically  a  medic,  hospital  corpsman  or 
combat  lifesaver)  makes  the  determination  of  the  level  of  precedence.  This  information  is 
important  in  the  sourcing  of  the  appropriate  platform(s)  to  handle  the  number  of 
casualties  and  where  to  take  the  casualties  after  pickup  [14]. 

Precedence  Descriptions: 

Urgent-the  patient  requires  emergency,  short  notice  evacuation  within  a 
maximum  of  two  hours  to  save  life,  limb,  or  eyesight  and  to  prevent  serious 
complications  of  the  injury,  serious  illness,  or  permanent  disability. 

Urgent  Surgical-the  patient  requires  forward  resuscitative  care  for  life  and  limb 
saving  measures,  and  to  attain  stabilization  for  further  evacuation. 

Priority-the  patient  requires  prompt  medical  care,  within  a  maximum  of  four 
hours,  to  prevent  the  medical  condition  from  deteriorating  to  an  Urgent  precedence  level, 
to  prevent  unnecessary  pain  or  disability,  or  who  require  treatment  not  available  locally. 

Routine-the  patient  who  does  not  require  immediate  medical  attention  and  whose 
condition  are  not  expected  to  deteriorate  significantly.  They  should  be  evacuated  within 
24  hours. 

Convenience-a  patient  for  whom  evacuation  by  medical  vehicle  is  a  matter  of 
medical  convenience  rather  than  necessity. 

When  passed  over  the  radio  the  radio  operator  will  announce  “Line  3”  followed 
by  the  letter  for  the  precedence  level  and  the  number  of  patients.  Eor  example,  “Line  3- 
A-3,B-1”  [14]. 
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4. 


Line  4:  Special  Equipment  Needed 


This  line  is  used  to  request  additional  support  for  the  patient  that  the  requesting 
unit  does  not  currently  have.  There  are  four  responses  for  this  line  each  associated  with  a 
letter  code  and  multiple  things  can  be  requested  by  the  unit.  They  are;  A-None,  B-Hoist, 
C-Extraction  Equipment  (jungle/forest  penetrator,  etc.),  and  D-Ventilator.  Upon 
requesting  additional  equipment  the  evacuation  platform  will  load  the  equipment  and 
have  it  available  for  the  requesting  unit  at  to  the  pickup  site  when  they  arrive.  When 
passed  over  the  radio  the  radio  operator  will  announce  “Eine  4”  followed  by  a  letter  or 
letters.  Eor  example,  “Eine  4-A”  [14]. 

5,  Line  5:  Number  of  Patients  by  Type 

This  line  is  used  to  ensure  the  platforms  sent  to  retrieve  the  casualties  are 
correctly  configured.  There  are  two  categories  for  this  line,  ambulatory  or  litter.  The 
determination  of  category  is  made  by  the  senior  medical  representative  on-scene.  An 
ambulatory  patient  can  move  under  his  or  her  own  power  and  their  injuries  do  not  prevent 
them  from  walking.  A  litter  patient  is  a  patient  who  cannot  move  under  his  or  her  own 
power  or  their  injury  prevents  them  from  doing  so,  thus  requiring  a  litter  to  be  moved. 
To  save  time,  a  letter  is  associated  with  each  type  with  “A”  representing  ambulatory  and 
“L”  representing  litter.  Also,  the  total  number  in  this  line  must  match  the  total  number  of 
patients  reported  earlier  in  Line  3.  When  passed  over  the  radio,  the  radio  operator  will 
announce  “Line  5”  followed  by  a  letter  with  a  number.  Eor  example,  “Line  5-A-8,  L-2” 
[14]. 


6,  Line  6:  Security  at  Pickup  Site 

This  line  is  used  to  provide  situational  awareness  for  the  pilots  and  determine  if 

the  evacuation  platform  is  going  to  need  assistance  from  escorts.  Since  medical  vehicles 

cannot  be  armed,  they  may  need  an  armed  escort  to  protect  them  as  they  approach  the 

pickup  site  and  during  the  evacuation.  The  unit  leader  ultimately  determines  the  security 

of  the  pickup  site  and  they  have  four  options  from  which  to  choose.  Eor  brevity  purposes 

the  choices  are  associated  letter  with  a  particular.  The  first  is  “No  enemy  troops  in  the 

area”  and  is  represented  by  “N.”  Next  is  “Possible  enemy  troops  in  the  area  (approach 
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with  caution)”  and  is  represented  by  “P.”  This  is  used  when  the  unit  is  unsure  if  enemy 
troops  are  in  the  loeal  area.  Next  is  “Enemy  troops  in  the  area  (approach  with  caution)” 
and  is  represented  by  “E.”  This  is  used  when  the  enemy  is  known  to  be  in  the  area  but 
only  presents  a  minor  threat.  The  final  option  is  “Enemy  troops  in  the  area  (armed  escort 
required)”  and  is  represented  by  “X.”  This  option  means  there  are  enemy  troops  in  the 
area  that  present  a  signifieant  threat.  When  passed  over  the  radio  the  radio  operator  will 
announce  “Eine  6”  followed  by  a  letter  with  a  number.  Eor  example,  “Eine  6-E”  [14]. 

7,  Line  7:  Method  of  Marking  Pickup  Site 

This  line  is  used  to  assist  the  evacuation  unit  in  finding  the  exact  location  of  the 
pickup  site  as  they  approach.  This  is  primarily  used  in  air  evacuation  but  can  also  be  used 
to  assist  ground  evaeuation.  The  unit  leader  makes  the  decision  on  how  to  mark  the 
piekup  site  based  on  the  situation  and  materials  at  his  disposal.  There  are  five  options, 
four  of  which  are  default  selections.  The  unit  commander  ean  seleet  panels,  pyroteehnic 
signals,  smoke  signals,  none,  or  other.  Eaeh  option  is  given  a  letter  for  brevity:  “A”  for 
panel,  “B”  for  pyrotechnic  signals,  “C”  for  smoke  signals,  “D”  for  none,  and  “E”  for 
other.  If  the  option  of  “other”  is  chosen,  the  unit  leader  needs  to  indieate  what  the  method 
will  be.  Eor  example,  if  an  infrared  buzz  saw  was  seleeted,  the  radio  operator  would  pass 
“E-infrared  buzz  saw.”  The  eolor  of  the  smoke  or  panels  is  never  passed  during 
transmission.  This  is  for  security  reasons,  as  the  pilot  will  identify  the  smoke  color  upon 
visual  acquisition.  He  will  indicate  over  the  radio  “I  see  red  smoke”  or  something  similar, 
and  the  unit  leader  will  affirm  to  the  pilot  that  he  has  aequired  the  correct  mark.  This  is 
done  to  prevent  the  enemy  trying  to  lure  in  the  evacuation  unit  to  a  false  EZ.  When 
passed  over  the  radio  the  radio  operator  will  announce  “Eine  7”  followed  by  a  letter.  Eor 
example,  “Eine  7-C”  [14]. 

8,  Line  8:  Patient(s)  Nationality  and  Status 

This  line  is  used  to  help  determine  the  destination  of  the  injured  patient  and  if  a 
guard  or  translator  is  required.  Similar  to  Line  5,  Line  8’s  total  must  match  the  count  in 
Line  3.  To  speed  up  transmission,  eaeh  option  is  assoeiated  with  a  letter.  The  options  are 
self-explanatory  and  are  as  follows:  A-United  States  Military,  B-United  States  Civilian, 
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C-  Non-United  States  Military,  D-  Non-United  States  Civilian,  and  E-Enemy  Prisoner  of 
War.  When  passed  over  the  radio  the  radio  operator  will  announce  “Eine  8”  followed  by 
a  letter  with  a  number.  Eor  example,  “Eine  8-C-8”  [14]. 

9.  Line  9:  Nuclear,  Biological  and  Chemical  Contamination 

This  line  is  used  to  determine  the  location  the  evacuation  unit  is  to  deliver  the 
patients  and  determine  the  Mission  Oriented  Protective  Posture  (MOPP)  level  of  the 
evacuation  unit.  If  a  patient  is  contaminated,  they  should  not  be  delivered  to  a  facility  that 
is  not  contaminated  or  do  not  have  the  resources  to  deal  with  a  contaminated  patient. 
There  are  four  options  for  this  line  with  associated  letters  for  brevity.  They  are  as  follows 
N-Nuclear,  B-Biological,  C-Chemical,  and  None.  If  “None”  is  selected,  the  individual 
simply  announces  “None”  over  the  radio.  When  passed  over  the  radio,  the  radio  operator 
will  announce  “Eine  9”  followed  by  a  letter  or  “None.”  Eor  example,  “Eine  9-None” 
[14]. 

F,  MEDEVAC/CASEVAC  PROCESSING 

A  complete  MEDEVAC  9-Eine  would  be  transmitted  over  the  radio  as  follows. 

“Eagle  this  is  Wolverine  stand  by  for  MEDEVAC  request,  break.” 

“Eine  1-1  lU  GS  123  456,  break.” 

“Eine  2-E123,  Wolverine,  break.” 

“Eine  3-A-3,  C-1,  break.” 

“Eine  4-A,  break.” 

“Eine  5-E-3,  A-1,  break.” 

“Eine  6-  P,  break.” 

“Eine  7-C,  break.” 

“Eine  8-A-3,  B-1,  break.” 

“Eine  9-None,  over.” 
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Following  this  transmission,  the  unit  that  received  the  MEDEVAC  request  will 
read  the  request  back  to  the  requesting  unit  to  ensure  all  information  was  correctly 
received. 

A  MEDEVAC  9-Eme  is  generated  in  one  of  two  ways  on  today’s  battlefield.  The 
individual  that  creates  the  MEDEVAC  request  typically  references  a  9-Line  template  and 
writes  the  information  out  on  a  separate  piece  of  paper.  Alternatively,  the  individual 
might  have  a  laminated  MEDEVAC  9-Line  template  that  they  circle  and  fill  in  the  blanks 
using  a  map  pen.  Either  way,  the  user  is  required  to  write  the  information  down  before 
sending  the  information  up  to  higher  headquarters  because  of  the  length  and  particular 
format  required.  Due  to  the  complexity  and  importance  of  the  task,  one  member  of  the 
unit  is  usually  assigned  the  primary  responsibility  of  the  generating  and  passing  the 
information  up  to  higher  elements.  In  addition,  there  is  always  at  least  an  alternate  and 
more  than  likely  multiple  individuals  assigned  this  task  in  case  the  primary  individual  is 
the  casualty.  The  experience  level  of  these  individuals  with  MEDEVAC  requests  is  based 
off  of  the  size  of  the  unit  and  the  amount  of  training  on  MEDEVAC  these  individuals 
have  received.  In  most  conventional  units,  the  top  five  leadership  positions  typically  have 
the  most  experience  on  MEDEVAC  9-Line  requests;  the  remaining  members  of  the  unit 
will  likely  have  little  to  no  training.  The  most  experienced  members  are  the  Platoon 
Commander,  Platoon  Sergeant,  and  the  three  squad  leaders.  While  all  these  individuals 
normally  have  the  most  exposure  to  the  MEDEVAC  9-Line  format,  usually  only  the 
Platoon  Commander  and  Platoon  Sergeant  have  been  extensively  trained  or  have  real-life 
experience  on  MEDEVAC  procedures.  This  creates  issues  when  units  operate  smaller 
than  platoon  size  elements,  which  has  become  more  normal  over  the  last  decade  of  war. 
To  help  eliminate  this  issue,  some  units  require  the  squads  to  send  their  MEDEVAC 
requests  to  the  platoon  first  and  the  Platoon  Sergeant  ensures  the  request  is  in  the  proper 
format  before  passing  the  request  to  higher  themselves,  even  if  the  squad  is  able  to 
communicate  with  higher  from  their  current  position.  Obviously,  this  creates  an 
additional  layer  that  increases  the  time  and  chances  of  errors  while  the  squad  could  have 
requested  MEDEVAC  directly. 
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After  the  individual  generating  the  request  has  all  required  information,  the 
request  is  transmitted  to  higher  elements.  This  is  typieally  aeeomplished  over  a  radio  net. 
Upon  receiving  the  request  the  receiving  will  read  back  the  request  to  verify  all 
information  is  correct.  The  information  is  then  entered  into  a  tactical  chat  window  on  a 
computer  that  is  monitored  by  all  units  in  theater.  If  a  receiving  unit  lacks  a  computer  to 
enter  the  request  into  the  chat  window,  the  request  is  passed  via  radio  to  the  next  level 
until  it  reaches  a  unit  with  the  proper  equipment.  From  there,  the  request  continues  to 
travel  up  the  chain  of  command  until  it  has  reached  the  appropriate  level  to  make  the 
decision  on  what  type  of  resources  can  be  dedicate  to  the  MEDEVAC  request.  Currently, 
this  is  usually  at  the  division  watch  officer  level.  After  the  platform  decision  has  been 
made,  the  requesting  unit  and  the  evacuation  unit  are  notified  of  the  decision  and  passed 
all  relevant  information. 

G.  EXPLOSIVE  ORDNANCE  DISPOSAL  FORMAT 

The  standard  UXO/IED  Spot  Report  for  all  services  is  as  follows:  [15] 

Line  1 -Date-Time-Group  when  the  device  was  discovered 

Line  2-Unit  Identification  and  location  of  lED/UXO 

Line  3-Contact  Method 

Line  4-Type  of  Ordnance 

Line  5-CBRNE  Contamination 

Line  6-Resources  threatened 

Line  7-Impact  on  Mission 

Line  8-Protective  Measures 

Line  9-Recommended  Priority 

Detailed  descriptions  of  the  individual  lines  are  as  follows. 

1,  Line  1:  Date-Time-Group 

This  line  is  used  to  inform  EOD  team,  or  higher  headquarters,  when  the  device 

was  discovered.  The  standard  time  date-time-group  is  DDHHMM(Z)MONYY.  When 

passed  over  the  radio,  the  radio  operator  will  announce  “Line  1”  followed  by  the  date- 

time-group.  Lor  example,  “Line  1-  07075 9JUN 14”  [15]. 
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2. 


Line  2:  Unit  Identiflcation  and  Location 


This  line  is  used  to  inform  whieh  unit  diseovered  the  deviee  and  the  approximate 
loeation  of  the  deviee.  The  loeation  of  the  lED  is  passed  using  8  digit  MGRS  whieh  gives 
a  preeision  of  10  meters.  While  getting  the  most  aecurate  loeation  of  the  lED  is 
important,  it  is  not  worth  risking  the  life  of  an  individual,  so  most  of  the  time  the  location 
is  estimated  as  accurately  as  possible.  When  passed  over  the  radio,  the  radio  operator  will 
announce  “Eine  2”  followed  by  the  unit  identification  and  lED  location.  Eor  example, 
“Eine  2-  1st  EAR,  Bravo  Company,  1st  Platoon,  1  lU  GR  1234  5678”  [15]. 

3.  Line  3:  Contact  Method 

This  line  is  used  to  pass  the  radio  frequency  and  call  sign  of  the  unit  requesting 
EOD  support.  This  allows  the  EOD  teams  to  directly  contact  the  unit  in  case  there  is  need 
for  more  information  or  most  likely  to  establish  a  link-up  point  with  the  ground  unit  to 
guide  the  EOD  team  to  the  device.  While  radio  frequency  and  call  sign  is  the  most 
common,  one  could  pass  a  point  of  contact  and  a  telephone  depending  on  the  location  of 
the  lED.  When  passed  over  the  radio,  the  radio  operator  will  announce  “Line  3”  followed 
by  the  radio  frequency  and  call  sign.  Eor  example,  “Line  2-F123,  Wolverines”  [15]. 

4.  Line  4:  Type  of  Ordnance 

This  line  is  used  to  announce  the  number  and  type(s)  of  ordnance  that  has  been 
found.  The  categories  for  these  are  projected  (fired  from  a  surface  weapon),  dropped 
(fired  from  an  aviation  platform),  placed  (put  on  the  ground),  thrown  (such  as  a  hand 
grenade),  or  possible  lED.  When  passed  over  the  radio  the  radio  operator  will  announce 
“Line  4”  followed  by  the  number(s)  and  type(s).  For  example  “Line  4-1  Dropped, 
2  Projected”  [15]. 

5.  Line  5:  CBRNE  Contamination 

This  line  is  used  to  inform  the  EOD  teams,  or  high  headquarter,  if  the  device 
appears  to  be  a  chemical,  biological,  radiological,  or  a  nuclear  device.  This  informs  the 
EOD  teams  if  they  need  to  bring  special  protective  equipment  to  the  site.  When  passed 
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over  the  radio,  the  radio  operator  will  announce  “Line  5”  followed  by  the  CBRNE 
contamination.  For  example,  “Line  5-None”  [15]. 

6.  Line  6:  Resources  Threatened 

This  line  is  used  to  report  what  assets  are  threatened  by  the  lED  or  UXO.  This 
information  is  used  in  conjunction  the  several  of  the  other  lines  to  determine  the  response 
of  the  EOD  team  by  higher  headquarters.  Because  the  teams  are  in  limited  supply,  higher 
headquarters  use  this  information  to  determine  which  requests  to  respond  to  first  by 
prioritizing  the  requests  that  have  the  most  impact  on  the  mission  or  threat  to  resources. 
Resources  could  include,  but  are  not  limited  to  equipment,  facilities,  civilian 
infrastructure,  etc.  When  passed  over  the  radio,  the  radio  operator  will  announce  “Line  6” 
followed  by  the  resources  that  are  threatened.  For  example,  “Line  6-local  school 
20  meters  to  the  Northeast”  [15]. 

7.  Line  7:  Impact  on  Mission 

This  line  is  used  to  help  inform  the  EOD  teams  and  high  headquarter  what  the 
tactical  situation  the  unit  is  facing  that  discovered  the  device.  This  line  should  be  as  short 
and  concise  as  possible  but  provide  enough  information  for  the  high  headquarters  to 
determine  the  priority  of  removing  the  device.  When  passed  over  the  radio,  the  radio 
operator  will  announce  “Line  7”  followed  by  the  impact  of  the  mission.  For  example 
“Line  7-currently  taking  small  fires  and  can’t  move  around  the  lED”  [15]. 

8.  Line  8:  Protective  Measure 

This  line  is  used  to  determine  the  appropriate  level  of  protection/escorts  needed 
by  the  EOD  team.  Protective  measures  can  range  from  establishing  a  complete  cordon  to 
nothing  at  all  depending  on  the  local  situation.  When  passed  over  the  radio,  the  radio 
operator  will  announce  “Line  8”  followed  by  the  protective  measures  taken.  For  example, 
“Line  8-200  meter  cordon  around  the  device  in  addition  to  an  over  watch  of  the 
surrounding  area”  [15]. 
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9,  Line  9:  Recommend  Priority 

This  line  is  used  to  relay  the  unit  commander’s  opinion  on  the  priority  of 
response.  The  unit  commander  can  choose  from  one  or  four  options.  They  are  as  follows: 

Immediate-stops  the  unit’s  maneuver  and  mission  capability,  or  threatens  critical 
assets  vital  to  the  mission 

Indirect-slows  the  unit’s  maneuver  and  mission  capability,  or  threatens  critical 
assets  important  to  the  mission 

Minor-reduces  the  unit’s  maneuver  and  mission  capability,  or  threatens 
noncritical  assets  of  value 

No  Threat-has  little  or  no  effect  on  the  unit’s  capabilities  or  assets 

While  temping,  unit  commanders  must  resist  inflating  the  priority  the  lED  has  on 
their  current  mission.  When  passed  over  the  radio,  the  radio  operator  will  announce  “Line 
9”  followed  by  the  unit’s  recommend  priority.  For  example,  “Line  9-  Indirect”  [15]. 

H,  EXPLOSIVE  ORDNANCE  DISPOSAL  REQUEST  PROCESSING 

A  complete  LOD  9-Line  would  be  transmitted  over  the  radio  as  follows. 

“Eagle  this  is  Dragon  stand  by  for  LOD  9-Line  request,  break.” 

“Line  1-271800ZMAY14,  break.” 

“Line  2-A  1/1,  18S  TU  135  485,  break 

“Line  3-LCpl  Smith,  Frequency  FI 23,  Callsign  Dragon,  break.” 

“Line  4-1  Possible  lED,  partially  buried  container  with  exposed  wires,  break.” 
“Line  5-None,  break.” 

“Line  6-Device  near  local  commerce  center,  break.” 

“Line  7-Patrol  halted,  break.” 

“Line  8-Dismounts  deployed  providing  cordon,  5s  and  25s  conducted,  break.” 
“Line  9-Indirect,  break.” 
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Following  this  transmission,  the  unit  that  received  the  EOD  request  will  read  the 
request  back  to  the  requesting  unit  to  ensure  all  information  was  correctly  received.  The 
request  will  then  be  routed  to  the  supporting  EOD  unit  for  prosecution. 

I.  RAPID  LOGISTICS  REQUEST  FORMAT 

Eor  application  development,  we  took  the  common  elements  of  the  rapid  logistics 
request  formats  we  researched  and  combined  them  into  a  common  format.  The  first  four 
lines  are  required,  and  lines  5-9  are  optional  depending  on  the  type  of  request.  The 
request  format  is  as  follows: 

1,  Line  1:  Unit  Name/POC 

This  line  is  to  inform  the  supporting  agency  for  with  whom  coordination  will 
occur.  Information  provided  in  this  line  includes  a  POC  name.  Unit  Name,  and 
Erequency/NetlD . 

2,  Line  2:  Precedence 

This  line  captures  the  relative  necessity  of  the  request.  The  options  include  routine 
(support  needed  within  72  hours),  priority  (support  needed  within  24  hours),  and 
emergency  (support  needed  as  soon  as  possible. 

3,  Line  3:  Type  of  Request 

This  line  indicates  what  type  of  support  the  user  is  requesting.  Options  include: 

•  Resupply-Used  to  indicate  that  the  user  needs  a  resupply  of  some  kind. 

•  Maintenance-Used  to  indicate  that  the  user  needs  support  from  higher 
echelon  maintenance  personnel. 

•  Vehicle  Recovery-Used  to  indicate  that  the  user  needs  assistance 
recovering  a  disabled  vehicle. 

•  Engineer  Support-Used  to  indicate  that  the  user  needs  assistance  from 
supporting  engineer  personnel. 

•  Pax/Cargo  Movement-Used  to  indicate  that  the  user  needs  assistance  from 
higher  headquarters  to  move  personnel  or  equipment. 
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4. 


Line  4:  Coordinating  Instructions 


This  line  is  used  to  provide  the  location  of  the  request  along  with  the  desired  time 
(as  soon  as  possible  or  a  particular  time).  Additionally,  the  user  can  provide  any 
amplifying  information  that  is  specific  to  the  situation  but  not  included  anywhere  else  on 
the  request  format. 

5.  Line  5:  Resupply 

This  line  is  populated  if  line  3  indicated  that  the  user  wanted  resupply  support. 
The  user  can  select  the  class  of  supply  needed  (I,  II,  III,  IV,  V,  VIII,  and  IX)  and  provide 
a  descrip tion/quantity  of  what  is  needed. 

6.  Line  6:  Maintenance  Contact 

This  line  is  populated  if  line  3  indicated  that  the  user  wanted  maintenance  contact 
support.  The  user  will  input  the  nomenclature  of  the  equipment  needing  repair  along  with 
a  description  of  the  problem. 

7.  Line  7:  Vehicle  Recovery 

This  line  is  populated  if  line  3  indicated  that  the  user  needs  vehicle  recovery 

support.  The  user  will  input  the  nomenclature  of  the  vehicle  along  with  a  description  of 
the  problem. 


8.  Line  8:  Engineer  Support 

This  line  is  populated  if  line  3  indicated  that  the  user  needs  engineering  support. 

The  user  can  select  from  the  following  options: 

•  Mobility-Used  when  the  user  needs  obstacle  reduction  and/or  to  maintain 
freedom  of  movement  by  maneuver  units. 

•  Countermobility-Used  when  the  user  needs  engineering  support  to 
construct  obstacles  to  delay,  disrupt  and  destroy  the  enemy  by 
reinforcement  of  terrain. 

•  Survivability-Used  to  indicate  that  the  user  needs  engineering  assistance 
to  construct/reinforce  facilities  to  protect  personnel  and  equipment. 

•  Horizontal  Construction-Used  to  indicate  that  the  user  needs  engineering 
assistance  to  shape  the  terrain  to  meet  the  operational  requirements  of  the 
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unit.  This  includes  route  eonstruetion,  expeditionary  airfields,  and  site 
preparations. 

•  Vertieal  Construetion-Used  to  indieate  that  the  user  needs  engineering 
support  to  eonstruet  expeditionary  fortifieations,  eamps,  and  maintenanee 
faeilities. 

•  Other-This  is  used  to  indieate  that  the  user  needs  engineering  support  that 
is  not  ineluded  above. 

Line  8  also  ineludes  a  seetion  to  provide  a  brief  deseription  of  the  support  needed 
by  the  unit. 

9,  Line  9:  Pax/Cargo  Movement 

This  line  is  populated  in  line  3  indieated  that  the  user  needs  movement  support. 
There  are  options  to  indieate  a  number  of  personnel,  eargo  weight/deseription  and  a 
destination  loeation. 

J.  RAPID  LOGISTICS  REQUEST  PROCESSING 

A  rapid  logisties  request  will  only  inelude  lines  1-4  and  whatever  lines  are 
indieated  by  line  3  (request  type).  An  example  request  for  resupply  would  be; 

“Eagle,  this  is  Dragon,  stand  by  for  Rapid  Logisties  Request,  break.” 

“Line  1:  POC  Lanee  Corporal  Smith,  A  1/1,  Frequeney  F123,  break” 

“Fine  2:  Routine,  break” 

“Fine  3:  Resupply,  break” 

“Fine  4:  ASAP,  18S  TU  135  485,  break” 

“Fine  5:  Class  1-3  DOS  Chow  and  Water  for  12  Marines,  break” 

“Fine  6,  7,  8,  9  Not  Entered,  Break” 

Following  this  transmission,  the  unit  that  reeeived  the  rapid  logisties  request  will 
read  the  request  baek  to  the  requesting  unit  to  ensure  all  information  was  eorreetly 
reeeived.  The  request  will  then  be  routed  to  appropriate  seetion/unit  for  proseeution. 
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K.  CURRENT  CHALLENGES  IN  TRAINING 


Based  on  the  eurrent  political  and  economic  climate,  the  Department  of  Defense 
(DoD)  is  likely  to  face  a  constrained  budget  for  the  foreseeable  future.  However,  this  is 
nothing  new  to  the  military  because  over  the  last  sixty  years  the  DoD  has  had  to  deal  with 
a  cycle  of  booms  and  busts.  Since  World  War  II  to  present,  the  DoD  has  had  to  face 
extreme  cuts  after  every  conflict.  In  addition,  over  the  last  sixty  years,  they  have  seen 
their  budget  steadily  reduce  as  a  percentage  of  Gross  Domestic  Product  from  nearly  40% 
during  World  War  II  to  a  projected  3.6%  in  2015  and  from  nearly  70%  of  the  Federal 
Budget  in  the  1950s  to  a  projected  15.6%  in  2015  [16].  The  constant  cycle  of  boom  and 
bust  along  with  a  steadily  decreasing  budget  relative  to  the  Federal  Budget  leads  to 
challenges  by  itself  Furthermore,  to  complicate  matters,  the  number  of  missions  the 
Department  of  Defense  is  responsible  for  has  steadily  expanded  over  the  years,  especially 
in  the  last  decade  [16].  No  longer  is  the  military  solely  responsible  to  fighting 
conventional  conflicts,  but  must  now  shoulder  the  responsibility  of  humanitarian 
assistance/  disaster  relief  (HA/DR),  national  building,  and  counter-terrorism.  The  issues 
of  limited  money  and  time  do  not  appear  to  be  persistent,  especially  with  the  challenges 
of  the  growing  cost  of  military  member  compensation  and  the  dynamic  nature  world 
events. 

While  the  budget  by  itself  is  an  issue,  wartime  provides  many  additional 
challenges.  Over  the  last  decade  of  constant  combat  operations,  operational  forces  within 
the  military  have  faced  many  challenges.  The  main  challenge  they  have  had  to  face  is  the 
rigorous  deployment  cycle.  At  the  height  of  combat  operations  some  units  faced  a  one-to- 
one  ratio  of  days  deployed  to  days  stateside  [17].  While  commanders  always  face  the 
challenge  of  limited  funds  to  conduct  training,  the  operational  tempo  has  compounded  the 
challenges  of  training  their  units  for  upcoming  deployment.  Like  most  individuals  they 
prioritized  their  goals  and  focused  on  accomplishing  their  top-level  goals  before 
deployment;  however,  this  naturally  leads  to  units  and  individuals  doing  very  well  at  a 
particular  task  but  they  lacked  breadth  across  all  functional  areas. 

The  Marine  Corps  is  no  different  from  any  other  service  when  it  comes  to  dealing 

with  the  challenges  of  limited  time  and  money;  we,  as  a  service,  have  to  prioritize  time 
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and  money.  In  the  realm  of  medieal  evaeuation  request,  reeruits  in  Boot  Camp  eurrently 
do  not  reeeive  any  formal  training  on  MEDEVAC  request,  EOD  request  in  their  initial 
training.  After  boot  eamp,  when  young  Marines  start  formal  training  for  their  military 
oeeupational  speeialty,  there  is  some  advaneed  medieal  training.  Eor  young  Marines 
going  into  the  infantry,  they  only  reeeive  an  additional  6.5  hours  of  medieal  training, 
3.5  hours  of  how  to  identify  an  lED  but  reeeive  no  formal  training  dealing  with  medieal 
evaeuation  requests  of  EOD  requests  in  over  300  hours  of  instruetion  at  the  Sehool  of 
Infantry  [18].  Individuals  not  going  to  the  infantry  reeeive  only  4.25  hours  of  advaneed 
medieal  training,  and  lED  training,  and  like  their  infantry  brethren;  they  do  not  reeeive 
any  training  on  medieal  evaeuation  requests  or  EOD  requests  [19].  Progressing  in  rank 
does  not  inerease  the  ehanees  of  reeeiving  formal  MEDEVAC  request  training  or  EOD 
request  until  a  deployment  is  on  the  horizon. 

The  next  formal  sehool  most  infantry  Marines  attend  in  their  eareer  is  Infantry 
Small  Unit  headers  Course,  whieh  is  a  Professional  Military  Edueation  (PME) 
requirement.  The  eourse  is  targeted  for  Sergeants  serving  as  squad  leader  of  seetion 
leaders.  Even  this  sehool,  whose  purpose  is  to  “develop  the  leadership,  deeision-making 
eapability,  and  profieieney  of  infantry  Sergeants... and  proeedural  profieieney  of  small 
unit  leaders,”  does  not  give  a  formal  elass  on  medieal  evaeuation  or  EOD  request 
proeedures  to  the  students  [20].  The  Marines  are  expeeted  to  have  aequired  the 
knowledge  before  starting  the  sehool  [20].  The  issue  with  this  is  that  these  are  the 
Marines  who  will  lead  12  to  15  personnel  in  foreign  eountries  without  an  Offieer  or  Staff 
NCO  present  and  may  faee  the  ehallenges  of  having  to  eall  in  a  MEDEVAC  or  EOD 
9-Eine  request  while  under  fire.  While  most  will  obtain  this  knowledge  through  self- 
studying  and  their  leadership  as  they  grow,  there  is  no  guarantee  this  will  happen.  If  the 
training  does  oeeur,  there  is  no  guarantee  that  the  training  knowledge  will  be  retained  by 
the  Marine  over  a  long  period  of  time,  espeeially  if  they  have  been  praetieing  it. 

With  the  eurrent  training  standards.  Marines  eould  potentially  serve  in  the  Marine 
Corps  for  eight  years  without  any  type  of  training  on  a  MEDEVAC  9-Eine  request  or 
EOD  requests.  The  main  issue  is  that  the  Marine  Corps  relies  on  the  infantry  battalions  to 
train  their  junior  Marines  and  young  leaders  on  requests  of  this  nature.  However,  infantry 
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battalions  are  constrained  by  limited  resources  (time,  money,  and  training  aids)  compared 
to  formal  schools  within  the  Marine  Corps.  While  unit  leaders  in  the  infantry  battalions 
can  provide  informal  classes  on  MEDEVAC  9-Eme  request  or  EOD  requests  to  all 
experience  levels,  they  typically  lack  the  ability  to  evaluate  the  Marines  properly. 
Because  of  these  time  constraints  normally  only  the  top  five  leadership  positions  in  the 
platoon  get  detailed  in-depth  training  on  MEDEVAC  9-Eine  requests  or  EOD  requests 
and  two  are  the  Platoon  Commander  and  Platoon  Sergeant.  In  addition,  these  individuals 
are  evaluated  on  a  regular  basis.  Their  evaluations  are  performed  informally  through 
company  staff  during  company  training  events  and  formally  by  outside  staff  during 
Enhanced  Mojave  Viper.  This  creates  a  critical  vulnerability  of  having  valuable 
knowledge  concentrated  into  the  hands  of  a  select  few.  With  83.5%  of  the  current  active 
duty  enlisted  Marines  being  a  Sergeant  or  below,  this  can  become  a  major  problem  in 
combat  since  one  does  not  get  to  pick  when  a  casualty  will  happen  or  who  will  be  present 
to  call  in  the  MEDEVAC  9-Eme  request  or  an  EOD  request  [21]. 

L,  WHY  SMARTPHONES  AND  ANDROID 

Currently  in  the  United  States,  over  60%  of  mobile  phone  users  use  a  smartphone, 
which  is  an  increase  of  over  10%  from  last  year  [22].  In  the  last  decade,  smartphones 
have  taken  over  50%  of  the  market  share  of  the  mobile  phones  sold  worldwide  [23].  In 
the  first  three  quarters  alone  of  2013,  over  261.1  million  smartphones  where  shipped  to 
end  users  around  the  world,  which  was  up  over  45%  from  the  year  before  [23],  [24]. 
Smartphones  offer  the  variety  of  functions  and  sensors  in  the  palm  of  user’s  hand.  They 
include:  accelerometer,  gyroscope,  compass,  GPS,  Wi-Ei,  camera,  telephony,  and 
processing  power  that  rivals  supercomputer  of  the  early  1980s.  Eurthermore,  while 
smartphones  increase  in  processing  power,  features,  and  functions  ever  year,  they  are  also 
becoming  more  affordable.  Many  experts  believe  for  a  number  of  tasks  they  could 
replace  the  personal  computer  in  the  near  future. 

While  there  is  no  doubt  that  smartphone  is  a  valuable  piece  of  technology  that  is 
being  leveraged  by  the  commercial  sector,  the  military  has  yet  to  fully  embrace  the  use  of 
smartphones.  The  military  is  not  against  the  use  of  smartphones  on  the  battlefield,  but 
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there  is  a  need  to  solve  several  challenges  the  commercial  sector  does  have  to  worry 
about.  The  two  primary  issues  are  connectivity  and  security.  The  number  one  reason  why 
smartphones  have  not  seen  wide  spread  use  in  the  military  is  the  lack  of  connectivity  on 
the  battlefield  or  at  sea.  Luckily,  in  the  past  few  years,  there  have  been  numerous 
technology  advances  that  seem  feasible  for  use  in  the  military  domain.  They  range  from 
middle  orbit  satellites  to  microwave  base  networks  for  naval  ships,  which  would  give 
ship  a  4G  LTE  network.  Both  of  these  technologies  have  been  tested  and  are  still  under 
development  [25],  [26]. 

There  is  currently  little  doubt  in  the  military  that  smartphones  could  be  leveraged 
on  the  battlefield  to  increase  lethality  and  effectiveness.  Some  day  in  the  not  too  distant 
future,  soldiers  will  carry  a  smartphone  into  battle  along  with  their  rifle  [27].  Besides 
many  other  questions,  this  brings  up  the  question  on  operating  systems:  which  is  the  best 
operating  system  for  the  military  use? 

Based  on  the  National  Security  Agency’s  (NSA)  approval  of  a  secure  version  of 
Android  Operating  system  for  use  in  the  military  on  networks  in  2013,  we  decided  that 
the  Android  Operating  system  was  ideal  for  the  testing  our  application  [28].  Finally,  the 
National  Security  Agency  is  currently  in  the  process  of  approving  the  Android  Operating 
system  for  approved  use  in  the  military  domain  for  use  on  secret  networks  [28]. 

M.  CURRENT  APPLICATIONS  ON  THE  MARKET 

We  found  four  applications  on  Google  Play  that  deal  with  a  MEDEVAC  9-Line 
request  they  are:  Basic  9  Line  MEDEVAC,  9-Line  MEDEVAC,  Army  Reports,  Army 
Leader  Smart  Cards  [29].  One  of  these  applications  {Army  Leader  Smart  Cards),  which 
is  more  of  a  reference,  provides  the  user  with  a  report  format  for  the  MEDEVAC  9-Eine 
request  with  a  brief  description  of  what  belongs  in  each  line,  as  well  as  formats  for 
several  other  important  reports  in  the  military.  The  other  three  applications  allow  the  user 
to  input  information  to  fill  out  a  MEDEVAC  9-Line  request.  One  application  {9-Line 
MEDEVAC)  is  self-described  as  a  “learning  tool”  to  help  the  user  practice  completing  the 
MEDEVAC  9-Line  request.  The  last  two  applications  {Basic  9  Line  MEDEVAC  and 
ARMY  Reports)  appear  to  be  intended  for  use  in  a  field  environment.  One  allows  the  user 
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to  send  information  via  text  message  and  the  other  provides  a  radio  transmission  template 
to  send  via  the  radio  after  the  user  inputs  information  needed  for  a  MEDEVAC  9-Line 
request.  However,  there  are  several  flaws  with  these  two  applieations  if  field  use  is  their 
goal.  Eirst,  the  applieations  did  not  take  in  eonsideration  the  stress  the  user  would  be 
under  in  trying  to  fill  out  the  form.  Both  applieations  laek  many  basie  and  important  time 
saving  features.  Basic  9  Line  MEDEVAC  does  not  allow  the  user  to  save  information  for 
later  use.  Army  Reports  laeks  a  helpful  hints  feature  for  inexperieneed  users,  and  both  of 
the  user  interfaees  are  not  optimized  for  a  user  under  stressful  eonditions.  The  next  issue 
is  that  only  one  applieation  allows  the  user  to  send  the  information  to  someone  else. 
However,  this  is  by  text  message  or  e-mail  and  provides  the  user  with  no  means  of 
informing  them  if  the  message  was  received.  In  addition,  security  is  an  issue  because  all 
MEDEVAC  9-Line  requests  are  required  to  be  encrypted,  but  these  methods  of  delivery 
are  not  encrypted.  Einally,  none  of  these  applications  have  Department  of  Defense 
approval,  which  again  leads  to  the  issue  of  security  and  approved  use  on  the  battlefield. 

Like  the  MEDEVAC  application  we  found  applications  that  are  available  on 
Google  Play  for  download,  but  there  were  only  two  applications  that  cover  lED/UXO 
reports.  The  first  was  Army  Leader  Smart  Cards,  which  also  contains  information  about 
MEDEVAC,  but  this  application  is  only  a  reference  that  shows  the  user  the  report  format. 
[30]  The  application  gives  a  brief  description  of  what  belongs  in  each  line  but  does  not 
allow  the  user  to  enter  any  information.  The  other  application,  Basic  9  Line  UXO-IED,  is 
a  self-described  training  application  [30].  This  application  gives  the  user  the  opportunity 
to  enter  information  for  each  line  and  e-mail  the  report  to  a  superior  for  review. 

The  challenges  that  face  the  Marines  Corps  in  getting  the  proper  training  to  the 
correct  individuals  is  vast  with  the  constraints  of  time  and  money,  and  because  of  this 
minor  but  important  training  is  given  little  to  no  time  at  all  in  the  training  schedule  or 
only  to  a  select  few.  Many  important  requests  (MEDEVAC,  EOD,  Rapid  Logistics 
Request)  fall  into  this  category  and  to  compound  matters  these  requests  are  required  to  be 
submitted  into  a  precise  format,  which  is  difficult  to  accomplish  by  an  individual  who 
lacks  the  appropriate  training  in  a  stressful  environment.  To  help  alleviate  this  potentially 
dangerous  and  deadly  situation  smartphones  with  applications  tailored  to  a  particular 
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request  ean  be  leveraged  to  reduee  the  ehanees  that  a  situation  would  happen  in  the 
future.  With  COTS  smartphones  with  applieation  speeifie  requests  the  Marine  Corps 
eould  aehieve  a  better  result  in  the  training  of  all  individuals  on  requests  with  no  more 
time  that  is  eurrently  being  used  and  aehieve  a  better  result.  However,  for  this  to  work  the 
applieation  must  be  speeifieally  tailored  for  use  in  a  stressful  environment  to  eliminate 
errors  and  help  the  user  with  the  request  as  mueh  as  possible  and  in  the  next  ehapter  the 
design  of  three  applieations  for  MEDEVAC,  EOD,  and  Rapid  Logisties  Request  will  be 
examined. 
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III.  DESIGN 


A.  SYSTEM  DESCRIPTION 

HELP  is  intended  to  provide  an  application  suite  for  warfighters  in  an  operational 
environment  to  call  for  resources  from  supporting  headquarters  [1].  It  walks  the  user 
through  several  standard  formats  for  calling  resources,  such  as  medical/casualty 
evacuation  (MEDE  VAC/ CASE  VAC),  rapid  logistics  request  and  EOD  support.  The 
application  suite  operates  on  a  smart  device  capable  of  running  the  Android  operating 
system,  and  utilizes  inherent  sensors  built  into  the  device.  The  smart  device  likely  be  a 
smart  phone  or  a  tablet,  which  is  compact  enough  for  an  infantryman  to  carry  while 
conducting  dismounted  operations. 

Erom  a  design  perspective,  HELP  needs  to  be  simple  enough  so  that  a  Marine 
with  little  to  no  prior  experience  with  standardized  message  formats  can  submit  a  request 
for  support  with  all  required  information  in  a  timely  manner  [1].  To  begin,  the  Marine 
simply  opens  the  proper  application  corresponding  to  his  needs  (MEDEVAC/CASEVAC, 
Rapid  Logistics  Request,  EOD  Request)  and  inputs  the  required  information. 

B,  CONCEPTUAL  DESIGN 

The  overall  system  architecture  consists  of  three  parts:  a  mobile  client, 
communications  network,  and  workstation  [1].  The  mobile  client  takes  information  and 
input  from  user  in  order  to  generate  a  properly  formatted  request.  The  request  is  then 
either  transmitted  via  voice  radio  or  digital  network  connectivity  to  the  user’s  higher 
headquarters  COC.  Einally,  the  watch  officer  at  the  receiving  headquarters  will  input  the 
information  into  Tactical  Chat  (TacChat)  by  either  manually  entering  the  information 
(from  a  voice  radio  transmission)  or  copying  and  pasting  the  information  (from  a  digital 
transmission). 

The  mobile  client  is  designed  for  use  on  an  Android  device.  The  client  suite  has 

been  implemented  in  native  Android  code  utilizing  the  Android  Software  Development 

Kit  (SDK).  A  Java-based  desktop  system  acting  as  a  server  is  required  for  connectivity 

and  digital  data  transmission.  Due  to  the  varying  message  formats  of  the  three  sample 
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requests  (MEDEVAC/  CASEVAC,  Rapid  Eogisties  Request,  EOD  Request),  we  have 
ereated  three  separate  applications,  one  for  each  type  of  request.  KEEP  is  likely  to  be 
used  in  austere  environments;  as  such,  the  conceptual  design  is  for  a  ruggedized  smart 
phone.  We  have  developed  and  tested  HELP  on  a  commercially  available  Samsung 
Galaxy  Nexus  (see  Eigure  1  for  dimensions). 


2.67  Inches 


Eigure  1 .  Samsung  Galaxy  Nexus  Dimensions,  from  [3 1  ] 

The  decision  to  develop  the  application  using  native  Android  was  swayed  by  the 
open-source  nature  of  the  operating  system  coupled  with  the  wide  variety  of  development 
tools  available  for  use.  Additionally,  any  smart  devices  running  Android  generally  has 
several  sensors  and  capabilities  available  for  the  system  to  draw  from.  The  capabilities 
we  are  interested  in  exploiting  are  the  global  positioning  system  (GPS)  capability, 
camera,  internal  database  storage,  and  WI-FI  capability.  These  assist  the  user  populate 
the  necessary  information  for  the  request  to  be  transmitted  and  acted  upon  by  their  higher 
headquarters. 
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A  working  prototype  of  the  HELP  suite  has  been  developed  during  this  thesis. 
The  remainder  of  this  seetion  eaptures  the  key  sereens  and  provides  a  deseription  of 
funetionality.  Eaeh  applieation  utilizes  a  weleome  sereen  and  a  swipe  navigation  scheme 
to  guide  the  user  through  the  lines.  The  final  screen  is  the  properly  formatted  call  for 
resources  that  the  user  can  either  call  over  the  radio  or  transmit  digitally,  if  network 
connectivity  is  available. 

C.  COMMON  FEATURES 

The  three  applications  that  make  up  the  HELP  suite  have  several  features  that  are 
common  to  them.  These  include: 

1.  Swipe  Navigation 

HELP  primarily  uses  swipe  navigation  to  enable  users  navigate  from  line  to  line 
of  their  request.  To  make  the  user  interface  simple,  we  wanted  to  separate  each  line  (of 
the  9  line  format)  on  a  separate  screen  and  enable  the  user  to  transition  from  one  line  to 
the  next.  Eor  such  transitions,  swiping  is  the  most  natural  gesture  for  touch  sensitive 
devices. 

2.  Haptic  Feedback 

The  HELP  suite  uses  the  device’s  built-in  vibration  capability  to  provide  haptic 
feedback  to  the  user  in  order  to  provide  a  tactile  response  when  the  user  enters  an  input. 
Vibration  feedback,  combined  with  visual  feedback,  greatly  assists  the  user  input  the 
required  information  during  a  stressful  scenario. 

3.  Color  Indicators 

We  use  a  red/green  color  schematic  to  provide  visual  feedback  to  the  user  when 
he  provides  input.  Prior  to  any  entry  by  the  user,  the  bottom  of  the  screen  is  red  to 
indicate  that  the  required  fields  have  not  been  populated.  Upon  correct  entry  of  the 
required  information,  the  color  changes  to  green  to  indicate  that  the  user  may  advance  to 
the  next  screen. 
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4. 


Deflnition  Windows 


We  designed  HELP  to  be  used  by  Marines  with  little  to  no  experienee.  To  make  it 
easy,  all  of  the  applications  in  HELP  are  designed  to  display  definitions  to  the  user  when 
needed.  If  the  user  is  unfamiliar  with  a  given  term,  he  may  simply  touch  the  term  and  a 
definition  display  pops  up. 

5.  Line  Generation 

All  three  of  the  requests  used  in  our  application  suite  have  specified  formats  that 
must  be  followed  in  order  for  the  supporting  headquarters  to  provide  timely  support.  All 
of  the  applications  take  the  user’s  input  and  translate  it  to  the  required  format  for  use  by 
any  supporting  headquarters. 

6,  Transmission  Control  Protocol 

When  available,  all  of  the  applications  use  simple  transmission  control  protocol 
(TCP)  connectivity  to  allow  for  speedy  transmission  of  the  request  to  a  supporting 
headquarters. 

D,  NETWORK  CONNECTIVITY 

All  of  the  HELP  applications  provide  connectivity  to  the  individual  Marines’ 
higher  headquarters  through  a  TCP  connection.  Currently,  the  server  is  a  simple  terminal 
program  that  listens  for  incoming  connections  from  users.  The  main  goal  for  network 
connectivity  is  to  reduce  the  transmission  time  and  eliminate  errors  that  can  occur  when 
reporting  data  by  over  the  voice  radio.  The  communications  chain  is  as  follows  and  is 
depicted  in  Eigure  2. 

1,  Smart  Device  to  Radio 

In  this  stage,  the  smart  device  has  two  options  to  connect  to  a  radio.  One  method 
is  wirelessly,  using  the  radio  as  a  WI-EI  hotspot.  This  connection  can  be  secured  through 
a  variety  of  means;  for  our  testing  we  used  WPA2  encryption.  The  second  option  is  to 
connect  the  Android  device  to  the  radio  via  a  connection  cable.  The  radio  we  used  during 
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testing  and  development  was  a  Persistent  Systems  Wave  Relay  Man  Portable  Unit  Gen 
4.1 


2,  Radio  to  Radio 

In  this  stage,  the  unit’s  radio  is  eommunieating  with  the  distant  end  radio  at  the 
unit’s  COC  via  VHP  transmission.  The  Persistent  Systems  Radio  is  eapable  of  enerypting 
this  transmission  in  a  variety  of  methods.  For  our  testing,  we  used  256  bit  AES-CTR  with 
HMAC-SHA  512  (Suite  B)  eneryption. 

3,  Radio  to  Workstation 

The  radio  at  the  COC  is  eonneeted  to  the  workstation  via  an  Ethernet  eable.  The 
formatted  request  is  displayed  on  the  workstation  terminal. 

4,  Tactical  Chat 

Upon  receipt  of  the  request  from  the  KEEP  client,  the  COC  watch  can  copy  the 
request  and  paste  it  into  the  appropriate  Tactical  Chat  (TacChat)  window  for  prosecution. 
Eor  example,  a  CASE  VAC  request  would  be  posted  to  the  theater/ AO 
MEDEVAC/CASEVAC  chat  window. 


1 


Product  can  be  seen  at  http://www.persistentsystems.com/man-portable-unit-gen4/ 
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Response  Platform 


Point  of 
Request 


Link  1:  802.11  Link  3:  Ethernet 

Link  2:  VHP 


it 


.  .c  ^ 


Platoon/Squad  Company  COC 

Figure  2.  HELP  Digital  Communications  Chain 


E.  APPLICATION  DESCRIPTIONS 

The  following  section  outlines  all  of  the  HELP  design  and  functionality.  Each 
screen  description  is  followed  by  a  figure  depicting  a  new  screen  with  numbered  arrows 
corresponding  to  the  outline  description.  A  second  figure  depicting  a  screen  resulting 
from  user  input  follows  the  first  figure. 

1,  HELP  Settings  Application 

The  HELP  Settings  application  is  the  central  application  to  the  HELP  Suite.  All 
other  applications  pull  information  from  the  HELP  Settings  application  to  auto-populate 
fields  in  other  applications  for  their  respected  request  [1],  This  application  is  populated 
prior  to  departure  on  any  mission. 
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a.  Settings  Screen 

Below  is  a  list  of  the  features  and  information  requiring  entry  into  the  HELP 
Settings  application.  A  screenshot  of  both  prior  to  data  entry  and  after  data  entry  is 
included  at  the  end  of  this  section. 

(1)  Navigation  Bar,  This  assists  the  user  by  indicating  what  screen  the 
user  is  currently  on.  All  application  settings  are  entered  on  this  one  screen. 

(2)  Current  Unit  ID,  This  is  the  current  Unit  Identifier  that  is 
currently  saved  in  the  system.  If  nothing  is  entered,  the  text  “Not  Entered”  is  displayed  in 
red.  Upon  entering  data,  the  text  changes  to  black. 

(3)  Update  Unit  ID  Button,  This  is  a  button  with  an  EditText^  field  to 
the  right.  When  the  user  inputs  his  unit  identifier  (i.e.,  1®‘  Platoon,  A  1/1)  and  presses  the 
Update  button,  the  data  is  stored  in  the  settings  SQLite  database. 

(4)  Current  Frequency/Net  ID,  This  is  the  current  frequency/net  ID 
that  is  currently  saved  in  the  system.  If  nothing  is  entered,  the  text  “Not  Entered”  is 
displayed  in  red.  Upon  entering  data,  the  text  changes  to  black. 

(5)  Update  Frequency/Net  ID  Button,  This  is  a  button  with  an 
EditText  field  to  the  right.  When  the  user  inputs  his  frequency/Net  ID  (i.e.,  EI23  or 
12.120)  and  presses  the  Update  button,  the  data  is  stored  in  the  settings  database. 

(6)  Current  Callsign,  This  is  the  current  callsign  that  is  currently 
saved  in  the  system.  If  nothing  is  entered,  the  text  “Not  Entered”  is  displayed  in  red. 
Upon  entering  data,  the  text  changes  to  black. 

(7)  Update  Callsign  Button,  This  is  a  button  with  an  EditText  field  to 
the  right.  When  the  user  inputs  his  callsign  and  presses  the  Update  button,  the  data  is 
stored  in  the  settings  database. 

(8)  Current  Higher  Headquarters  IP  Address,  This  is  the  current 
higher  headquarters  IP  address  that  is  currently  saved  in  the  system.  If  nothing  is  entered, 
the  text  “Not  Entered”  is  displayed  in  red.  Upon  entering  data,  the  text  changes  to  black. 


^  EditText:  This  is  an  Android  widget  that  allows  the  user  of  a  system  to  type  in  a  text  input. 
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(9)  Update  Higher  Headquarters  IP  Address  Button,  This  is  a 
button  with  an  EditText  field  to  the  right.  When  the  user  inputs  his  higher  headquarters’ 
IP  address  and  presses  the  Update  button,  the  data  is  stored  in  the  settings  database. 

(10)  Current  Higher  Headquarters  Port,  This  is  the  eurrent  higher 
headquarters  port  that  is  eurrently  saved  in  the  system.  If  nothing  is  entered,  the  text  “Not 
Entered”  is  displayed  in  red.  Upon  entering  data,  the  text  ehanges  to  blaek. 

(11)  Update  Higher  Headquarters  Port  Button,  This  is  a  button  with 
an  EditText  field  to  the  right.  When  the  user  inputs  his  higher  headquarters’  port  and 
presses  the  Update  button,  the  data  is  stored  in  the  settings  database. 

(12)  Test  Connection  Button,  This  button  tests  eonneetivity  with  the 
higher  headquarters  server  based  upon  the  eurrent  IP  address  and  port.  A  Toast^  indieates 
a  sueeessful  eonneetion. 

(13)  Clear  Settings  Button.  This  button  clears  all  of  the  current 
settings  and  set  them  to  “Not  Entered.” 


3  Toast:  This  is  an  Android  widget  that  displays  a  pop-up  warning  to  the  user  with  text.  Throughout 
this  applieation,  a  Toast  indieates  a  warning. 
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HELP 

(1)  SETTINGS 


Figure  3.  HELP  Settings  Prior  to  User  Input 


^  HELP  Settings 

SETTINGS 


Unit  ID  1st  Platoon,  A  1/3 
Update  ex  -'I  latt  ■■■  I  ' 

Frequency/Net  ID  FI  68 
Update  -  .  II 

Callsign:  Archer 
Update  Unit  Callsign 

Higher  HQ  IP  Address: 

172.20.154.28 

Update  ex 

Higher  HQ  Port:  4445 
Update  ex  *4##  Of 

Test  Connection 

Figure  4.  HELP  Settings  After  User  Input 
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2. 


CASEVAC  Application 


The  CASEVAC  application  is  intended  to  help  generate  a  MEDEVAC  request.  In 
this  section,  each  screen  in  the  application  is  explained  in  depth. 

a.  Welcome  Screen 

The  purpose  of  this  screen  is  to  inform  the  user  about  the  basic  functionality  of 
our  application.  The  screen  describes  how  to  reach  the  settings  application,  how  to 
navigate  to  the  different  lines,  and  how  to  display  the  definitions  of  unfamiliar  terms. 


O  CASEVAC 

INTRODUCTION 

Welcome 

• 

• 

m 

Access  the  settings  at 

the  top  right 

t 

=  t 

Use  your  finger  to 

swipe  between  lines. 

Click  on  unfamiliar 

(/ 

terms  to  get  a 

definition 

*  _ 

Eigure  5.  CASEVAC  Welcome  Screen 


b.  Line  1:  Landing  Zone  Location 

The  purpose  of  line  1  is  to  indicate  where  a  rotary-wing  aircraft  can  land  in  order 
to  transport  the  injured  Marine.  The  screen  breaks  down  the  line  into  the  following  areas; 

(1)  Navigation  Bar,  This  assists  the  user  by  indicating  what  line  he  is 

currently  on. 

(2)  Line  Title,  Indicates  the  title  of  the  line. 
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(3)  Use  GPS  Button.  This  button  calls  the  system’s  GPS  to  populate 
the  current  latitude  and  longitude.  The  latitude  and  longitude  is  used  to  create  the  line  1 
information. 

(4)  Latitude  EditText  Box.  This  allows  the  user  to  manually  enter  the 
desired  pickup  site  latitude. 

(5)  Longitude  EditText  Box.  This  allows  the  user  to  manually  enter 
the  desired  pickup  site  longitude. 

(6)  Use  Manual  Lat/Long  Button.  Onee  the  user  populates  the 
latitude  and  longitude,  this  button  creates  line  1  using  the  input  information.  If  the 
latitude  or  longitude  is  blank,  the  system  displays  a  warning  to  the  user  via  a  Toast. 

(7)  MGRS  EditText  Box.  This  allows  the  user  to  manually  enter  the 
desired  piekup  site  Military  Grid  Referenee  System  grid. 

(8)  Use  Manual  MGRS  Button.  Onee  the  user  populates  the  MGRS 
grid,  this  button  creates  line  1  using  the  input  information.  If  the  MGRS  EditText  box  is 
blank,  the  system  provides  a  warning  via  a  Toast. 

(9)  Line  1  Preview.  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
GPS  lat/long  or  manual  entry  of  coordinates,  the  background  color  changes  to  green  and 
line  information  populates,  indieating  that  the  user  is  ready  to  move  to  the  next  line. 
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Figure  6.  CASEVAC  Line  1  Prior  to  User  Input 
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Figure  7.  CASEVAC  Line  1  After  User  Input 
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c.  Line  2:  Frequency/Callsign 

The  purpose  of  line  2  is  to  provide  the  responding  unit  with  radio  eontaet 
information  for  the  unit  that  has  suffered  the  injury.  The  response  platform  will 
eventually  need  to  speak  with  the  unit.  The  sereen  breaks  down  the  line  into  the  following 
areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Saved  Data  Field,  This  field  is  populated  if  the  user  has 
previously  entered  a  frequency/net  ID  and  callsign  in  the  settings  application. 

(4)  Use  Presets  Button,  This  button  is  used  when  the  user  wants  to 
utilize  the  saved  settings  indicated  in  the  previous  field.  Once  pressed,  the  system  creates 
line  2  with  the  saved  information. 

(5)  Frequency/Net  ID  EditText,  This  field  is  used  to  manually  input 
the  frequency  or  net  ID.  This  is  used  when  the  user  needs  to  use  a  different  frequency  or 
net  ID  from  the  presets. 

(6)  Callsign  EditText,  This  field  is  used  manually  input  the  desired 
callsign.  This  is  used  when  the  user  needs  to  use  a  different  callsign  from  the  presets. 

(7)  Use  Manual  Entry  Button,  This  button  is  used  when  the  user 
wants  to  use  the  manually  entered  frequency/net  ID  and  callsign.  The  system  generates  a 
Toast  warning  when  the  either  of  the  required  fields  is  left  blank. 

(8)  Line  2  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  utilizing  the 
presets  or  manually  entering  the  frequency/net  ID,  the  background  color  changes  to  green 
and  line  information  will  populate,  indicating  that  the  user  is  ready  to  move  to  the  next 
line. 
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Figure  9.  CASEVAC  Line  2  After  User  Input 
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d.  Line  3:  Casualties  by  Precedence 

The  purpose  of  line  3  is  to  assist  higher  headquarters  determine  how  many 
response  platforms  will  be  dispatched  and  to  where  the  platforms  will  deliver  the  injured 
Marines.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Urgent  Count  Field,  This  field  indicates  the  number  of  patients 
that  the  senior  medical  representative  categorizes  as  urgent.  To  the  left  and  right  of  the 
field  are  two  image  buttons"^,  one  for  incrementing  up  and  another  for  incrementing 
down.  Pressing  either  of  these  increases  or  decreases  the  integer  count  displayed  in  the 
field.  Touching  the  text  to  the  right  of  the  button  displays  a  definition  of  the  term. 

(4)  Urgent  Surgical  Count  Field,  This  field  indicates  the  number  of 
patients  that  the  senior  medical  representative  categorizes  as  urgent  surgical. 

(5)  Priority  Count  Field,  This  field  indicates  the  number  of  patients 
that  the  senior  medical  representative  categorizes  as  priority. 

(6)  Routine  Count  Field,  This  field  indicates  the  number  of  patients 
that  the  senior  medical  representative  categorizes  as  routine. 

(7)  Convenience  Count  Field,  This  field  indicates  the  number  of 
patients  that  the  senior  medical  representative  categorizes  as  convenience. 

(8)  Line  3  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  increasing  any  of 
the  count  fields,  the  background  changes  to  green.  Additionally,  the  total  count  on  this 
line  is  used  to  validate  lines  5  and  8  to  ensure  the  user  enters  matching  patient  counts.  If 
the  user  decreases  all  fields  to  0,  the  background  changes  back  to  red  and  the  text  resets 
to  “Line  3:  Not  Entered.” 


^  Image  Button:  This  is  an  Android  widget  that  turns  an  image  into  a  button  with  funetionality. 
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Figure  10.  CASEVAC  Line  3  Prior  to  User  Input 
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Figure  1 1 .  CASEVAC  Line  3  After  User  Input 
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e.  Line  4:  Special  Equipment 

The  purpose  of  line  4  is  to  indicate  to  the  flight  crew  any  special  equipment  that 
might  be  needed  to  assist  with  the  extraction  of  the  injured  Marines.  The  screen  breaks 
down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  “None”  Checkbox^,  When  this  checkbox  is  checked,  no  special 
equipment  is  needed  for  extract.  If  any  of  the  other  boxes  on  this  screen  are  checked  and 
the  user  checks  this  box,  the  system  unchecks  all  of  the  other  boxes  automatically. 
Additionally,  if  this  box  is  checked,  and  another  selection  is  made,  the  “None”  box 
unchecks. 

(4)  “Hoist”  Checkbox,  This  checkbox  should  be  checked  if  a  hoist  is 
needed  to  extract  the  patient(s).  A  hoist  is  used  in  situations  where  a  helicopter  is  unable 
to  land  (usually  due  to  terrain).  Touching  the  text  to  the  right  of  the  button  displays  a 
definition  of  the  term. 

(5)  “Extraction  Equipment”  Checkbox,  This  checkbox  should  be 
checked  if  particular  extraction  equipment  is  needed  to  extract  the  patient.  This  will  be 
followed  up  with  a  radio  call  to  the  higher  headquarters  combat  operations  center  with  a 
description  as  to  what  is  needed.  An  example  of  this  would  be  a  forest  or  jungle 
penetrator  in  cases  of  thick  foliage. 

(6)  “Ventilator”  Checkbox,  This  checkbox  should  be  checked  to 
indicate  that  the  patient(s)  need  assistance  breathing.  The  crew  will  bring  a  ventilator  or 
additional  personnel  to  assist  with  cardiopulmonary  resuscitation. 

(7)  “Other”  Checkbox,  This  checkbox  should  be  checked  to  indicate 
that  the  patient  needs  some  other  type  of  special  equipment  that  is  not  listed.  The 
EditText  to  the  right  of  the  title  is  populated  by  the  user  to  indicate  what  equipment  is 
needed. 


^  Checkbox:  This  is  an  Android  widget  that  allows  the  user  to  check  the  box  if  something  is  true.  A 
logical  call  to  the  field  will  return  “True”  if  the  box  is  checked,  and  false  otherwise. 
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(8)  Line  4  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  checking  any  of 
the  check  boxes,  the  background  turns  green  and  updates  the  line  with  the  applicable 
information  (letter  codes).  The  background  changes  back  to  red  and  the  text  resets  to 
“Line  4:  Not  Entered”  if  the  user  unchecks  all  of  the  boxes. 
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Figure  12.  CASEVAC  Line  4  Prior  to  User  Input 
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Figure  13.  CASEVAC  Line  4  After  User  Input 
f.  Line  5:  Number  of  Patients  by  Type 

The  purpose  of  line  5  is  to  further  assist  with  the  deeision  of  what  type  and  how 
many  response  platforms  to  dispateh.  A  large  number  of  litter  patients  eould  neeessitate  a 
platform  eonfigured  to  carry  a  large  amount  of  litters.  The  screen  breaks  down  the  line 
into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Reminder,  This  field  reminds  the  user  of  the  number  of  casualties 
he  previously  entered  in  line  3.  This  helps  to  ensure  that  the  total  number  of  casualties  in 
line  3  matches  that  of  this  line. 

(4)  Litter  Count  Field,  This  field  indicates  the  number  of  litter 
patients.  Litter  patients  are  defined  as  those  who,  due  to  the  severity  of  wounds,  are 
unable  to  walk  by  themselves.  To  the  left  and  right  of  the  field  are  two  image  buttons, 
one  for  incrementing  up  and  another  for  incrementing  down.  Pressing  either  of  these  will 
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increase  or  decrease  the  integer  count  displayed  in  the  field.  Touehing  the  text  to  the  right 
of  the  button  displays  a  definition  of  the  term. 

(5)  Ambulatory  Count  Field,  This  field  indicates  the  number  of 
ambulatory  patients.  Ambulatory  patients  are  those  who  have  reeeived  minor  wounds  and 
are  able  to  walk  by  themselves. 

(6)  Line  5  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  The  text  changes  upon 
pressing  either  of  the  “up”  image  buttons  to  indicate  the  number  of  casualties  by  type. 
The  baekground  ehanges  to  green  if  the  total  eount  matches  the  total  easualties  indicated 
in  line  3.  It  turns  back  to  red  if  the  number  shifts  at  all  (up  or  down)  to  not  match  the 
count  in  line  3.  The  text  resets  to  “Line  5;  Not  Entered”  if  the  user  zeros  out  both  fields. 
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Figure  14.  CASEVAC  Fine  5  Prior  to  User  Input 
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Figure  15.  CASEVAC  Line  5  After  User  Input 


g.  Line  6;  Security  at  Pickup  Site 

The  purpose  of  line  6  is  to  educate  the  responding  pilot  about  the  security  in  the 
area  around  the  unit.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  “No  Enemy”  Radio  Button^,  The  user  selects  this  radio  button  if 
there  are  no  indications  of  enemy  activity  in  the  area.  Touching  the  text  to  the  right  of  the 
button  displays  a  definition  of  the  term. 

(4)  “Possible  Enemy  Troops”  Radio  Button,  The  user  selects  this 
radio  button  if  there  is  potential  for  enemy  activity  in  the  area.  This  selection  informs  the 
responding  platform  to  approach  with  caution. 


®  Radio  Button:  This  is  an  Android  Widget  that  allows  the  user  to  seleet  a  single  item  from  several  in  a 
list.  Multiple  seleetions  are  not  possible. 
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(5)  “Enemy  Troops  in  Area”  Radio  Button,  The  user  selects  this 
radio  button  if  enemy  troops  are  present,  but  not  within  small-arms  range  of  the  LZ.  This 
selection  informs  the  responding  platform  to  approach  with  caution. 

(6)  “Armed  Escort  Required”  Radio  Button,  The  user  selects  this 
radio  button  if  enemy  troops  are  present  with  a  quantity/capability  to  potentially  interfere 
with  the  CASEVAC  platform.  This  also  drives  the  decision  to  launch  armed  aircraft  as 
escorts. 

(7)  Line  6  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  clicking  one  of 
the  radio  buttons,  the  background  color  changes  to  green  and  the  text  changes  to 
represent  the  selection. 
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Figure  16.  CASEVAC  Line  6  Prior  to  User  Input 
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Figure  17.  CASEVAC  Line  6  After  User  Input 
h.  Line  7:  Method  of  Marking  Pickup  Site 

The  purpose  of  line  7  is  to  inform  the  pilot  of  the  response  platform  of  the  method 
of  marking  the  landing  zone.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  “Panels”  Checkbox,  The  user  will  select  this  checkbox  if  he 
desires  to  mark  a  landing  zone  using  reflective  panels.  Touching  the  text  to  the  right  of 
the  button  displays  a  definition  of  the  term. 

(4)  “Pyrotechnic  Signals”  Checkbox,  The  user  will  select  this 
checkbox  if  he  desires  to  mark  the  landing  zone  with  a  pyrotechnic  signal,  such  as  a  flare. 

(5)  “Smoke”  Checkbox,  The  user  will  select  this  checkbox  if  he 
desires  to  mark  the  landing  zone  with  a  smoke  grenade  or  similar  technique. 

(6)  “None”  Checkbox,  The  user  will  select  this  checkbox  if  he  will 
not  mark  the  landing  zone  or  if  he  has  not  yet  determined  the  appropriate  mark.  Selecting 
“None”  will  not  prevent  the  CASEVAC  platform  from  launching.  He  will  need  to 
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coordinate  with  the  pilot  en  route  to  the  landing  zone  for  terminal  eontrol.  Touehing  the 
text  to  the  right  of  the  button  displays  a  definition  of  the  term.  If  the  user  selects  this  box, 
any  other  boxes  that  are  checked  will  be  unchecked.  If  this  box  is  checked  and  the  user 
seleets  another  box,  it  will  uneheek. 

(7)  “Other”  Checkbox  and  EditText  Field,  The  user  will  mark  this 
eheekbox  if  he  will  use  a  marking  teehnique  other  than  panels,  pyroteehnie  signal  or 
smoke.  For  example:  an  Infrared  Chemlight  “Buzzsaw”  or  NATO  Y  . 

(8)  Line  7  Preview.  Initially  this  has  a  red  baekground  to  indieate  to 
the  user  that  he  is  not  done  completing  the  neeessary  information.  Upon  elieking  one  of 
the  eheekboxes,  the  baekground  eolor  ehanges  to  green  and  the  text  ehanges  to  represent 
the  seleetion.  Any  modifieation  to  the  “Other”  EditText  field  will  also  ehange  upon 
typing  via  keystroke  listener. 


^  IR  Buzzsaw:  Technique  of  marking  a  landing  zone  in  low  light  situations  achieved  by  attaching  an 
infrared  chemlight  to  a  length  of  cord  and  spinning  it  at  high  speeds.  This  is  visible  to  pilots  using  night 
vision  goggles. 

^  NATO  Y :  Technique  of  marking  a  landing  zone  using  chemlights  strung  together  in  the  shape  of  the 
letter  “Y”.  The  direction  of  the  Y  indicates  in  which  direction  the  troops  on  the  ground  desire  the  aircraft  to 
land. 
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Figure  18.  CASEVAC  Line  7  Prior  to  User  Input 


Figure  19.  CASEVAC  Line  7  After  User  Input 
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L  Line  8:  Patient  Nationality  and  Status 

The  purpose  of  line  8  is  to  inform  higher  headquarters  and  the  response  platform 
about  the  nationality  and  status  of  the  patients.  United  State  Military  patients  may  or  may 
not  go  to  the  same  hospital  as  civilians,  and  foreign  nationals  might  fall  under  different 
medical  rules  of  engagement.  Prisoners  of  war  might  require  an  armed  guard.  The  screen 
breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Reminder,  Same  description  as  previous  (Line  5). 

(4)  “U,S,  Military”  Count  Field,  This  field  indicates  the  number  of 
patients  that  are  U.S.  Military.  To  the  left  and  right  of  the  field  are  two  image  buttons, 
one  for  incrementing  up  and  the  other  for  decrementing.  Pressing  either  of  these  will 
increase  or  decrease  the  integer  count  displayed  in  the  field.  Touching  the  text  to  the  right 
of  the  button  displays  a  definition  of  the  term. 

(5)  “U,S,  Civilian”  Count  Field,  This  field  indicates  the  number  of 
patients  that  are  U.S.  Civilians.. 

(6)  “Non-U,S,  Military”  Count  Field,  This  field  indicates  the  number 
of  patients  that  are  Non-U.  S.  Military  (such  as  partnered/allied  nation  forces). 

(7)  Non-U,S,  Civilian  Count  Field,  This  field  indicates  the  number  of 
patients  that  are  Non-U.S.  Civilians  (such  as  interpreters  or  aid  workers). 

(8)  “EPW”  Count  Field,  This  field  indicates  the  number  of  patients 
that  are  Enemy  Prisoners  of  War. 

(9)  Line  8  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  The  text  changes  upon 
pressing  either  of  the  “up”  image  buttons  to  indicate  the  number  of  casualties  by  type. 
The  background  changes  to  green  if  the  total  count  matches  the  total  casualties  indicated 
in  line  3.  It  will  turn  back  to  red  if  the  number  shifts  at  all  (up  or  down)  to  not  match  the 
count  in  line  3.  The  text  will  reset  to  “Line  5:  Not  Entered”  if  the  user  zeros  out  both 
fields. 
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NOTE:  You  previously  indicated  in  LINE  3  that 
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Figure  20.  CASEVAC  Line  8  Prior  to  User  Input 
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NOTE:  You  previously  indicated  in  LINE  3  that 
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0  ©  EPW 


Figure  2 1 .  CASEVAC  Line  8  After  User  Input 
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j.  Line  9:  Nuclear,  Biological,  Chemical  Contamination 

The  purpose  of  line  9  is  to  warn  the  response  platform  about  the  presenee  of  any 
contamination  in  the  area.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Line  Description,  Same  description  as  previous. 

(4)  “None”  Checkbox,  The  user  will  select  this  checkbox  if  there  is 
no  contamination  in  the  area.  If  other  checkboxes  are  checked  and  the  user  selects 
“None,”  the  other  boxes  will  uncheck.  Additionally,  if  this  box  is  checked  and  the  user 
selects  a  level  of  contamination,  the  “None”  box  will  uncheck. 

(5)  “Nuclear”  Checkbox,  The  user  will  select  this  if  there  is  nuclear 
contamination  in  the  area  (fallout  from  nuclear  weapons,  disasters  involving  nuclear 
power  plants,  etc). 

(6)  “Biological”  Checkbox,  The  user  will  select  this  if  there  is 
biological  contamination  in  the  area. 

(7)  “Chemical”  Checkbox,  The  user  will  select  this  if  there  is 
chemical  contamination  in  the  area. 

(8)  Line  9  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  checking  any  of 
the  check  boxes,  the  background  will  turn  green  and  update  the  line  with  the  applicable 
information  (letter  codes).  The  background  changes  back  to  red  and  the  text  will  reset  to 
“Line  4:  Not  Entered”  if  the  user  unchecks  all  of  the  boxes. 


62 


O  CASEVAC 


REVIEW 


NBC  Contamination 


None 
'  Nuclear 
Biological 
Chemical 


Line  9  Not  Entered 


Figure  22.  CASEVAC  Line  9  Prior  to  User  Input 


O  CASEVAC  : 

LINE,  LINE  9  REV 


NBC  Contamination 


Figure  23.  CASEVAC  Line  9  After  User  Input 
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k.  Final  9-Line 

The  purpose  of  the  final  line  is  to  provide  the  user  with  a  ehance  to  review  his  or 
her  inputs  and  send  the  request  by  his  or  her  preferred  method  (digital  or  voice).  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Line  Description,  Instructs  the  user  to  review  the  information  in 
the  9-Line  and  press  the  “Digital”  button  to  transmit  digitally  or  “Voice”  button  to 
display  the  voice  transmission  format. 

(4)  Line  Data,  This  is  the  plaintext  version  of  the  user’s  input  that  was 
used  to  populate  the  lines.  This  is  in  plain  English  vice  line  data  format  for  ease  of  review 
by  the  user.  The  data  is  properly  formatted  prior  to  digital  transmission  or  display  to  the 
user  for  voice  transmission. 

(5)  “Digital”  Image  Button,  This  puts  some  connectivity  information 
and  line  data  into  an  array  for  transmission  to  the  sender’s  higher  headquarters.  The 
information  is  sent  as  a  string  array  containing  the  following: 

•  Index  0:  The  string  “CASE VAC.”  The  distant  end  uses  this 
string  for  identifying  what  type  of  message  is  being 
received. 

•  Index  1 :  String  containing  the  plaintext  unit  title  to  inform 
the  supporting  headquarters  from  whom  the  CASEVAC 
request  is  originating. 

•  Index  2:  String  containing  the  Internet  protocol  (IP)  address 
of  the  sending  device.  This  is  used  for  the  distant  end  to 
acknowledge  receipt. 

•  Index  3:  String  containing  line  1. 

•  Index  4:  String  containing  line  2. 

•  Index  5:  String  containing  line  3. 

•  Index  6:  String  containing  line  4. 

•  Index  7:  String  containing  line  5. 

•  Index  8:  String  containing  line  6. 

•  Index  9:  String  containing  line  7. 

•  Index  10:  String  containing  line  8. 

•  Index  1 1 :  String  containing  line  9 
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(6)  “Voice”  Image  Button,  This  button  displays  the  9-Line  in  proper 
format  for  digital  transmission.  This  is  used  when  there  is  no  digital  eonneetivity. 

(7)  Final  9-Line  Indicator,  Initially  this  has  a  red  background  to 
indicate  to  the  user  that  he  has  not  transmitted  the  9-Line  to  his  higher  headquarters. 
Upon  pressing  the  “Digital”  button,  the  application  transmits  the  data  array  to  the  IP 
address  and  port  as  indicated  in  the  preset  settings.  Upon  receipt  by  the  user’s  higher 
headquarters,  an  acknowledgement  message  is  sent  back  and  the  background  color 
changes  to  green  and  the  text  changes  to  “Acknowledged  By  Server.” 


mu  OCASEVAC 

£1) _  't9  REVIEW 

pT"  final  9-line 


through  to  review  the  9-ljne  Press  either  the 
button  to  send  digitally  or  the  votce  button  to 

Linel  MGRSISS  TU  345  467 

_ Line  2  (Frequency/Callsign): 

BH^Vcquency  -  F1 68,  Callsign  -  Archer 

Line  3  (Casualties  by  Precedence): 

2  Urgent,  1  Urgent  Surgical 

Line£^S£ecial E2Ui£ment^|e€ded2^ 

Digital _ Voice 


Final  9-Line  Not  Sent 


Figure  24.  CASE  VAC  Final  9-Line 
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Figure  25.  CASEVAC  Voice  Format  Display 


O  CASEVAC 
LINE  9  REVIEW 

FINAL  9-LINE 


Scroll  Ihrough  lo  rwiew  the  9-Une  Pres*  either  the 
digitaJ  button  to  send  digitally  or  the  voice  button  to 
diaplEV  the  voice  foimai _ 

Line  1  M6RS  1 8S  TU  345  467 

Line  2  (Frequency/Callsign) 
Frequency  -  FI  68,  Callsign  -  Archer 

Line  3  (Casualties  by  Precedence): 

2  Urgent,  1  Urgent  Surgical 

LinM^S£ecial E2ui£menUteeded)^ 


Digital _ Voice 


Acknowledged  By  Server 


Figure  26.  CASEVAC  Einal  9-Eine  After  Digital  Transmission 
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3.  EOD/UXO  Application 

The  EOD/UXO  application  is  intended  to  help  generate  an  EOD/UXO  request.  In 
this  section,  each  screen  in  the  application  is  explained  in  depth. 

a.  Welcome  Screen 

This  screen  is  to  inform  the  user  about  basic  functionality  of  the  application.  The 
screen  describes  how  to  reach  the  settings  application,  how  to  navigate  to  the  different 
lines,  and  how  to  display  the  definitions  of  unfamiliar  terms. 


UXO/EOD 


WELCOME  LINE  1 


Introduction 


Access  the  settings  at 
the  top  right. 


t 


Use  your  finger  to 
swipe  between  lines. 


Click  on  unfamiliar 
terms  to  get  a 
definition. 


Figure  27.  UXO/EOD  Welcome  Screen 


b.  Line  1:  Date  Time  Group 

The  purpose  of  the  line  is  to  indicate  to  the  responding  EOD  team  what  time  the 
device  or  ordnance  in  question  was  found.  The  user  has  several  options  to  populate  the 
time  the  item  was  found.  The  screen  breaks  down  the  line  into  the  following  areas; 

(1)  Navigation  Bar,  This  assists  the  user  by  indicating  what  line  he  is 

currently  on. 
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(2)  Line  Title.  Indicates  the  title  of  the  line. 

(3)  “Use  Current  Time”  Button.  This  button  generates  the  current 
date  time  group  (DTG)  to  indicate  the  time  that  the  ordnance  was  found.  A  military  DTG 
is  formatted  as  DDTTTTZMMMYY.  DD  indieates  the  two  digit  date  of  the  month, 
TTTT  indicates  the  24  hour  time,  Z  indicates  the  current  time  zone  (if  other  than 
Zulu/Greenwich  Mean  Time),  MMM  indieates  the  three  letter  abbreviation  for  the  month, 
and  YY  indicates  the  two  digit  year. 

(4)  Manual  Time  Entry  EditText.  This  field  is  for  the  user  to 
manually  enter  in  a  time  the  ordnance  was  found.  This  would  be  used  if  another  entity 
(adjacent  unit  without  communication  capability,  local  national  civilian,  etc)  discovered 
the  ordnance  at  a  previous  time. 

(5)  “Manual  Entry”  Button.  This  button  generates  the  DTG  based 
upon  the  user’s  input  into  the  above  EditText  field.  If  the  EditText  field  is  blank,  an  error 
Toast  is  generated  and  displayed  to  the  user. 

(6)  Line  1  Preview.  Initially  this  has  a  red  baekground  to  indicate  to 
the  user  that  he  is  not  done  eompleting  the  neeessary  information.  Upon  either  selecting 
the  eurrent  DTG  button  or  manual  entry  button,  the  baekground  will  turn  green  and 
update  the  line  with  the  applicable  information  (DTG  ordnance  was  found).  The 
background  changes  baek  to  red  and  the  text  will  reset  to  “Line  1:  Not  Entered”  if  the 
user  tries  to  change  his  entry  to  a  manual  entry  with  nothing  populated  for  the  EditText 
field. 
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Group 


Use  Current  Time 


2:  Manual  FnJry  (DTG  or 


rr  _  DD  I  '  ■  ‘  II" 

Manual  Entry 


Line  1 :  Not  Entered 


Figure  28.  UXO/EOD  Line  1  Prior  to  User  Input 


UXO/EOD  : 

WELCOME  LINE  1  LINE  2 

Date  Time  Group 


Option  1 :  Use  Current  Date/Time 


Figure  29.  UXO/EOD  Line  1  After  User  Input 
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c.  Line  2:  Reporting  Activity 

The  purpose  of  line  2  is  to  indicate  the  unit  that  found  the  device  or  ordnance.  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  Current  Unit  ID,  This  field  is  populated  by  the  HELP  Settings 
database  that  is  set  by  the  user. 

(4)  “Use  GPS”  Button,  This  button  causes  the  line  data  to  be  created 
using  the  device’s  GPS  in  latitude/longitude. 

(5)  “Manual  MGRS”  EditText,  This  field  is  for  the  user  to  manually 
enter  the  location  of  the  ordnance  using  MGRS. 

(6)  “Use  Manual  MGRS  Input”  Button,  This  button  is  used  after  the 
user  inputs  a  manual  MGRS  grid  in  the  above  field.  If  the  entry  is  blank,  an  error  Toast  is 
generated.  If  there  is  an  entry  in  the  above  field,  the  line  information  is  generated. 

(7)  Line  2  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  either  selecting 
the  “Use  GPS”  button  or  manual  entry  button,  the  background  will  turn  green  and  update 
the  line  with  the  applicable  information  (Unit  ID  and  Location).  The  background  changes 
back  to  red  and  the  text  will  reset  to  “Line  2:  Not  Entered”  if  the  user  tries  to  change  his 
entry  to  a  manual  entry  with  nothing  populated  for  the  EditText  field. 
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UXO/EOO 


Reporting  Activity 


Use  GPS 


Enter  your  unit  identtficatton  and  locacion _ | 

1  St  Platoon,  A  1/3 


Location  (jpiion  2  Manual  MGRS  t 


MGRS 

Use  Manual  MGRS  Input 


Line  2:  Not  Entered 


Figure  30.  UXO/EOD  Line  2  Prior  to  User  Input 


^  UXO/EOD  : 

ilNEl  LINE  2  LINE  3 

Reporting  Activity 


_ Enter  your  unit  identification  and  location _ 


Unit  ID  Presets 


1st  Platoon,  A  1/3 


Figure  3 1 .  UXO/EOD  Line  2  After  User  Input 
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d.  Line  3:  Contact  Method 

During  any  EOD  response,  the  responding  team  must  eonduct  eoordination  with 
the  unit  that  found  the  device.  Line  3  establishes  the  unit  name  and  point  of  contact 
information.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “POC  Name”  EditText,  This  field  is  used  to  populate  the  primary 
point  of  contact  with  whom  coordination  will  occur  by  supporting  explosive  ordnance 
disposal  personnel. 

(4)  Saved  Frequency/NetID,  This  field  is  populated  by  the  HELP 
Settings  database  that  is  set  by  the  user.  This  indicates  the  current  frequency  that  the 
requesting  unit  is  monitoring. 

(5)  Saved  Callsign,  This  field  is  populated  by  the  HELP  Settings 
database  that  is  set  by  the  user.  This  indicates  the  current  callsign  of  the  requesting  unit. 

(6)  “Use  Presets”  Button,  This  button  creates  the  line  data  with  the 
presets  that  are  currently  displayed.  If  the  button  is  pressed  without  an  entry  in  the  POC 
Name  field,  an  error  Toast  will  remind  the  user  to  populate  a  primary  POC. 

(7)  Manual  Frequency/NetID  EditText,  This  field  is  populated  by 
the  user  if  he  wants  to  use  a  different  Frequency/NetID  than  what  is  currently  saved  in  the 
settings  database. 

(8)  Manual  Callsign  EditText,  This  field  is  populated  by  the  user  if 
he  wants  to  use  a  different  callsign  than  what  is  currently  saved  in  the  settings  database. 

(9)  “Use  Manual  Entry”  Button,  This  button  is  pressed  after  the  user 
enters  the  previous  two  fields.  If  one  or  both  of  the  fields  are  left  blank,  an  error  Toast  is 
displayed  to  remind  the  user  to  complete  the  entries. 

(10)  Line  3  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  either  selecting 
the  “Use  Presets”  button  or  “Use  Manual  Entry”  button,  the  background  will  turn  green 
and  update  the  line  with  the  applicable  information  (POC,  Frequency/NetID,  Callsign). 
The  background  changes  back  to  red  and  the  text  will  reset  to  “Line  3:  Not  Entered”  if 
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the  user  tries  to  ehange/alter  his  entry  to  a  manual  entry  with  nothing  populated  for  the 
proper  EditText  fields. 


UXO/EOD 


Contact  Method 


OC  Name  Nrimp-Rani 


Option  I  Use  Presets 


Saved  Frequency 

FI  68 

Saved  Callsign 

Archer 


Use  Presets 


Opi-on  2  Use  Manual  f"try 


Frequency/Net  ID 
Callsign 
Use  Manual  Entry 


Line  3  Not  Entered 


Figure  32.  UXO/EOD  Fine  3  Prior  to  User  Input 
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dH  UXO/EOD 


LINE  4 


IINE2  LINES 

Contact  Method 


POC  Name  Sergeant  Smith 


Line  2:  POC  -  Sergeant  Smith, 
Frequency  FI  68,  Callsign  Archer 


Figure  33.  UXO/EOD  After  User  Input 
e.  Line  4:  Type  of  Ordnance 

The  purpose  of  line  4  is  to  provide  the  responding  EOD  team  with  basie 
information  about  the  quantity  of  deviees.  Onee  this  information  is  known,  the  EOD  unit 
can  further  task  organize  for  a  proper  response.  The  screen  breaks  down  the  line  into  the 
following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  Dropped  Count  Field,  This  field  indicates  the  number  of  dropped 
ordnance  devices.  Dropped  ordnance  are  those  which  have  been  dropped  by  an  aviation 
platform  but  failed  to  detonate/function.  To  the  left  and  right  of  the  field  are  two  image 
buttons,  one  for  incrementing  up  and  the  other  for  decrementing.  Pressing  either  of  these 
will  increase  or  decrease  the  integer  count  displayed  in  the  field.  Touching  the  text  to  the 
right  of  the  button  displays  a  definition  of  the  term. 

(4)  Projected  Count  Field,  This  field  indicates  the  number  of 
projected  ordnance  devices.  Dropped  ordnance  are  those  which  have  been  fired  from  an 

indirect  fire  weapon  system,  such  as  an  artillery  piece,  but  failed  to  detonate/function. 
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(5)  Placed  Count  Field.  This  field  indicates  the  number  of  placed 
ordnance  devices.  Dropped  ordnance  are  those  which  have  been  out  into  position  by  a 
person.  An  example  of  placed  ordnance  might  be  a  weapons  cache  or  munitions  dump. 

(6)  Possible  Improvised  Explosive  Device  (lED)  Count.  Dropped 
Count  Field.  This  field  indicates  the  number  of  possible  lEDs.  Improvised  Explosive 
Devices  are  devices  that  are  homemade  and  function  in  ways  other  than  conventional 
means. 

(7)  Thrown  Count  Field.  This  field  indicates  the  number  of  thrown 
devices.  Thrown  devices  are  things  such  as  hand  grenades  that  failed  to 
function/  detonate . 

(8)  Amplifying  Information  EditText.  This  field  is  populated  to  give 
any  sort  of  amplifying  information  to  EOD  personnel  that  might  help  prepare  them  for 
the  disposal  mission.  A  user  might  indicate  a  brief  description  of  the  device(s),  and 
indications  of  tampering,  command  wires,  or  any  other  pertinent  information. 

(9)  Line  4  Preview.  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  increasing  any  of 
the  device  count  fields,  the  background  changes  to  green  to  indicate  to  the  user  that  the 
required  information  has  been  populated.  The  background  changes  back  to  red  and  the 
text  will  reset  to  “Eine  4:  Not  Entered”  if  the  user  decreases  all  of  the  device  counts  to  0. 


75 
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Figure  34.  UXO/EOD  Line  4  Prior  to  User  Input 
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Line  4:  Total  UXO/IEDs  - 1 .  By 
Category  -  Projected  - 1 .  Additional 
Information:  1 55MM  Arty  Shell 


Figure  35.  UXO/EOD  Line  4  After  User  Input 
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f.  Line  5:  CBRNE  Contamination 

The  presence  of  CBRNE  contamination  during  any  operation  is  critical 
information.  Line  5  provides  the  EOD  team  with  any  information  about  potential 
contamination.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “None”  Checkbox,  This  is  checked  by  the  user  when  there  is  no 
indication  of  Chemical,  Biological,  Radiological,  or  Nuclear  contamination. 

(4)  “Nuclear”  Checkbox,  This  checkbox  is  checked  by  the  user  if 
there  is  any  presence  of  nuclear  contamination. 

(5)  “Biological”  Checkbox,  This  checkbox  is  checked  by  the  user  if 
there  is  any  presence  of  biological  contamination. 

(6)  “Chemical”  Checkbox,  This  checkbox  is  checked  by  the  user  if 
there  is  any  presence  of  chemical  contamination. 

(7)  “Amplifying  Information”  EditText,  This  field  is  for  the  user  to 
provide  any  additional  information  about  the  contamination  present. 

(8)  Line  5  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  increasing 
checking  any  of  the  boxes,  the  background  changes  to  green  to  indicate  to  the  user  that 
the  required  information  has  been  populated.  The  background  changes  back  to  red  and 
the  text  will  reset  to  “Line  5:  Not  Entered”  if  the  user  deselects  all  of  the  checkboxes. 
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Indicate  any  potential  chemical.  biok>gicai  or  nudear 
contaminahon  potential 


None 

Nuclear 

Biological 

Chemical 

Amplifying  Information 


Line  5:  Not  Entered 


Figure  36.  UXO/EOD  Line  5  Prior  to  User  Input 


^  UXO/EOD 
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Line  5:  None 


Figure  37.  UXO/EOD  Line  5  Prior  to  User  Input 
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g.  Line  6:  Resources  Threatened 

The  purpose  of  line  6  is  to  give  higher  headquarters  an  indication  of  any  critical 
resources  or  infrastructure  that  might  be  threatened  by  an  lED  or  ordnance.  This 
information  can  help  prioritize  the  response.  The  screen  breaks  down  the  line  into  the 
following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Resources  Threatened”  EditText,  This  field  is  populated  by  the 
user  to  indicate  what,  if  any,  resources,  facilities,  or  assets  are  threatened  by  the  device 
being  reported. 

(4)  Line  6  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
above  field,  the  color  changes  from  red  to  green.  The  background  changes  back  to  red 
and  the  text  will  reset  to  “Line  6:  Not  Entered”  if  the  user  deletes  the  entry  to  the  above 
field. 


^  UXO/EOD 


Resources  Threatened 


Repon  any  equipment,  faalilies.  or  other  assets  that 
are  threatened 

Etilei  :<  descriptiuri  o*  what  resoutces 
could  potentially  be  affected  by  the 
detonation  of  the  device 


Line  6  Not  Entered 


Eigure  38.  UXO/EOD  Line  6  Prior  to  User  Input 
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LINE  6 


LINE 


UXO/EOD 

LINE  5 

Resources  Threatened 


Report  any  equipment,  facilities,  or  other  assets  that 
are  threatened. 

Dud  artillery  shell  is  in  hazardous 
proximity  to  local  national  commerce 
area] 


Line  6:  Dud  artillery  shell  is  in 
hazardous  proximity  to  local 
national  commerce  area. 


Figure  39.  UXO/EOD  Line  6  After  User  Input 
h.  Line  7:  Impact  on  Mission 

The  purpose  of  line  7  is  to  provide  higher  headquarters  with  a  snapshot  of  how  the 
ordnance  or  lED  is  affecting  the  current  mission.  This  also  helps  prioritize  the  response. 
The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Impact  on  Mission”  EditText,  This  field  is  populated  by  the 
user  to  indicate  what  impact,  if  any,  the  device  is  having  on  the  unit’s  current  mission. 

(4)  Line  7  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
above  field,  the  color  changes  from  red  to  green.  The  background  changes  back  to  red 
and  the  text  will  reset  to  “Line  7:  Not  Entered”  if  the  user  deletes  the  entry  to  the  above 
field. 
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^  UXO/EOD 


Impact  on  Mission 


Provide  a  short  description  of  your  current  tactiat 
situation  and  how  the  presence  of  the  UXO/IED 
affects  your  status 

^nief  3  description  of  what  impact  the 
presence  of  the  device  is  having  on  your 
mission 


Line  7:  Not  Entered 


Figure  40.  UXO/EOD  Line  7  Prior  to  User  Input 


UXO/EOD 


Impact  on  Mission 


Provide  a  short  description  of  your  current  tactial 
situation  and  how  the  presence  of  the  UXO/IED 
affects  your  status 

Patrol  halted  and  conducting  survey  of 
local  populace  for  any  additional 
information. 


Line  7:  Patrol  halted  and  conducting 
survey  of  local  populace  for  any 
additional  information. 


Figure  41 .  UXO/EOD  Line  7  After  User  Input 
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L  Line  8:  Protective  Measures 

The  purpose  of  line  8  is  to  further  develop  the  situational  awareness  of  higher 
headquarters  about  what  the  discovering  unit  is  doing  to  protect  personnel  and 
equipment.  This  also  helps  prioritize  a  response.  The  screen  breaks  down  the  line  into  the 
following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Protective  Measures”  EditText,  This  field  is  populated  by  the 
user  to  indicate  what  protective  measures,  if  any,  the  unit  has  taken  to  mitigate  risk  from 
the  device(s). 

(4)  Line  8  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
above  field,  the  color  changes  from  red  to  green.  The  background  changes  back  to  red 
and  the  text  will  reset  to  “Line  8:  Not  Entered”  if  the  user  deletes  the  entry  to  the  above 
field. 


(d  UXO/EOD 


Protective  Measures 


Describe  any  measures  taken  to  protect  personnet 
and  equipment 

Enter  a  desrnptron  of  what  protectrvt- 
nieusures  you  are  taking 


Line  8.  Not  Entered 


Figure  42.  UXO/EOD  Line  8  Prior  to  User  Input 
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Figure  43.  UXO/EOD  Line  8  After  User  Input 
j.  Line  9:  Recommended  Priority 

The  purpose  of  line  9  is  to  assist  higher  headquarters  prioritize  a  response.  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Immediate”  Radio  Button,  The  user  selects  this  when  the 
presence  of  the  ordnance  has  stopped  the  unit’s  maneuver  and  mission  capability  or 
threatens  critical  assets  vital  to  their  mission.  Clicking  on  the  text  displays  a  definition  of 
“Immediate.” 

(4)  “Indirect”  Radio  Button,  The  user  selects  this  when  the  presence 
of  the  ordnance  has  slowed  the  unit’s  maneuver  and  mission  capability  or  threatens 
critical  assets  important  to  the  mission.  Clicking  on  the  text  displays  a  definition  of 
“Indirect.” 
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(5)  “Minor”  Radio  Button,  This  is  selected  by  the  user  when  the 
presence  of  the  ordnance  reduces  the  unit’s  maneuver  and  mission  capability  or  threatens 
non-critical  assets  of  little  value.  Clicking  on  the  text  displays  a  definition  of  “Minor.” 

(6)  “No  Threat”  Radio  Button,  This  is  selected  by  the  user  when  the 
presence  of  the  ordnance  presents  little  or  no  threat  to  the  unit’s  mission.  Clicking  on  the 
text  displays  a  definition  of  “No  Threat.” 

(7)  Line  9  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
above  field,  the  color  changes  from  red  to  green.  The  background  changes  back  to  red 
and  the  text  will  reset  to  “Line  9;  Not  Entered”  if  the  user  deletes  the  entry  to  the  above 
field. 


p 

1  (2) 

P  UXO/EOD 

NE8  LINE? 

Recommended  Priority 

Recommend  a  prionly  for  response  by  EOO 

technicians 

y  Immediate 

^3  Indirect 

'  Minor 

1^0  No  Threat 

1  Line  9  Not  Entered 

Figure  44.  UXO/EOD  Line  9  Prior  to  User  Input 
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LINE  9 


REVIEW 


^  UXO/EOD 


Recommended  Priority 


Recommend  a  priority  for  response  by  EOD 
technicians. 


Immediate 
Indirect 
c-  Minor 
No  Threat 


Line  9:  Minor 


Figure  45.  UXO/EOD  Line  9  After  User  Input 


k.  Final  9-Line 

The  purpose  of  the  final  line  is  to  provide  the  user  with  a  chance  to  review  his  or 
her  inputs  and  send  the  request  by  his  or  her  preferred  method  (digital  or  voice).  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Line  Description,  Instructs  the  user  to  review  the  information  in 
the  9-Line  and  press  the  “Digital”  button  to  transmit  digitally  or  “Voice”  button  to 
display  the  voice  transmission  format. 

(4)  Line  Data,  This  is  the  plaintext  version  of  the  user’s  input  that  was 
used  to  populate  the  lines.  This  is  in  plain  English  vice  line  data  format  for  ease  of  review 
by  the  user.  The  data  is  properly  formatted  prior  to  digital  transmission  or  display  to  the 
user  for  voice  transmission. 
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(5)  “Digital”  Image  Button.  This  puts  some  connectivity  information 
and  line  data  into  an  array  for  transmission  to  the  sender’s  higher  headquarters.  The 
information  is  sent  as  a  string  array  containing  the  following: 

•  Index  0:  The  string  “UXOEOD.”  The  distant  end  uses  this  string 
for  identifying  what  type  of  message  is  being  received. 

•  Index  I:  String  containing  the  plaintext  unit  title  to  inform  the 
supporting  headquarters  from  whom  the  UXO/EOD  request  is 
originating. 

•  Index  2:  String  containing  the  Internet  protocol  (IP)  address  of  the 
sending  device.  This  is  used  for  the  distant  end  to  acknowledge 
receipt. 

•  Index  3:  String  containing  line  1. 

•  Index  4:  String  containing  line  2. 

•  Index  5:  String  containing  line  3. 

•  Index  6:  String  containing  line  4. 

•  Index  7:  String  containing  line  5. 

•  Index  8:  String  containing  line  6. 

•  Index  9:  String  containing  line  7. 

•  Index  10:  String  containing  line  8. 

•  Index  1 1 :  String  containing  line  9 

(6)  “Voice”  Image  Button.  This  button  displays  the  9-Eine  in  proper 
format  for  digital  transmission.  This  is  used  when  there  is  no  digital  connectivity. 

(7)  Final  9-Line  Indicator.  Initially  this  has  a  red  background  to 
indicate  to  the  user  that  he  has  not  transmitted  the  9-Eine  to  his  higher  headquarters. 
Upon  pressing  the  “Digital”  button,  the  application  transmits  the  data  array  to  the  IP 
address  and  port  as  indicated  in  the  preset  settings.  Upon  receipt  by  the  user’s  higher 
headquarters,  an  acknowledgement  message  is  sent  back  and  the  background  color 
changes  to  green  and  the  text  changes  to  “Acknowledged  By  Server.” 
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I0(  UXO/EOD 


FINAL  9-LINE 


lease  review  the  following  9-Line  If  it  is  correct 
ess  (he  digital  bollon  to  transmit  digitally  or  the 
yoic^jjlloiUodisgb^h^OjcMofma^^^^^^ 


Line  1:  DTG  - 152028Z  MAY  14 


ine  2:  Unit  ID  -  1st  Platoon,  A  1/3, 
cation -18S  TU  148  385 


Line  2;  POC  -  Sergeant  Smith.  Frequenc> 
FI  68,  Callsign  Archer 

Line_4j^otal_UXO/IEDs^2i_B^_Cate20i2 


Digital  Voice 


Final  9-Line  Not  Sent 


Figure  46.  UXO/EOD  Final  9-Line  Review 


Figure  47.  UXO/EOD  Voice  Format  Display 
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UXO/EOO 

iNEO  REVIEW 

FINAL  9-LINE 


Please  review  the  following  9-ljne  ll  il  is  cortecV 
press  Ihe  digital  fauiion  lo  transmit  digitaHv  oi  the 
jrojc^KitloiH^l*jj|s^h^fojc^oiina^^^^^^^^ 

Linel  DTG  -152028ZMAY14 

Line  2  Unit  ID  - 1  si  Platoon,  A  1  /3, 
Location  -  18S  TU  148  385 

Line  2  POC  -  Sergeant  Smith,  Frequency 
FI  68,  Callsign  Archer 

Line  4:  Total  UXO/IEDs  - 1 .  8y  Category 

m 

Digital _ Voice 


Acknowledged  By  Server 


Figure  48.  UXO/EOD  Final  9-Line  After  Digital  Transmission 

4,  Rapid  Request  Application 

The  Rapid  Request  application  is  intended  to  help  generate  a  Rapid  Logistics 
request.  In  this  section,  each  screen  in  the  application  is  explained  in  depth. 

a.  Welcome  Screen 

This  screen  is  to  inform  the  user  about  basic  functionality  of  the  application.  The 
screen  describes  how  to  reach  the  settings  application,  how  to  navigate  to  the  different 
lines,  and  how  to  display  the  definitions  of  unfamiliar  terms. 
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Figure  49.  Rapid  Request  Welcome  Screen 

b.  Line  1:  Unit  Name/POC 

The  purpose  of  line  1  is  to  identify  the  requesting  unit  to  higher  headquarters.  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  This  assists  the  user  by  indicating  what  line  he  is 

currently  on. 

(2)  Line  Title,  Indicates  the  title  of  the  line. 

(3)  Point  of  Contact  (POC)  Name  EditText,  This  field  is  used  to 
indicate  the  primary  point  of  conduct  with  whom  any  coordination  will  occur. 

(4)  Saved  Unit,  This  is  the  saved  Unit  ID  that  is  currently  saved  in  the 
HELP  Settings  database. 

(5)  Saved  Frequency/NetID,  This  is  the  saved  Frequency/NetID  that 
is  currently  saved  in  the  HELP  Settings  database. 

(6)  “Click  to  Use  Presets”  Button,  This  button  is  pressed  if  the  user 
desires  to  use  the  preset  unit  ID  and  frequency/NetID.  If  the  primary  POC  field  is  left 
blank,  an  error  Toast  is  displayed  to  the  user. 
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(7)  “Manual  Unit  Entry”  EditText,  This  field  is  populated  by  the 
user  if  he  does  not  want  to  use  the  unit  ID  eurrently  saved  in  the  settings  database. 

(8)  Manual  Frequency/NetID  EditText,  This  field  is  populated  by 
the  user  if  he  does  not  want  to  use  the  frequeney/NetID  saved  in  the  settings  database. 

(9)  “Manual  Entry”  Button.  This  is  pressed  by  the  user  upon 
completion  of  the  previous  two  fields.  If  either  of  the  previous  fields  were  left  blank,  an 
error  Toast  is  displayed  to  the  user. 

(10)  Line  1  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
proper  fields  and  pressing  either  the  Use  Presets  or  Manual  Entry  buttons,  the  color 
changes  from  red  to  green.  The  background  changes  back  to  red  and  the  text  will  reset  to 
“Line  1 ;  Not  Entered”  if  the  user  deletes  required  information  and  attempts  to  press  either 
of  the  buttons. 


^  Rapid  Request 


Unit  Name/POC 


OC  Name:  asr.i-.  r-r 


Option  1  Use  I  1  Preset* 


1  St  Platoon,  A  1  /3 

Saved  Freauencv/Net  ID 

if!  68 

Click  to  Use  Presets 

noKEasi 

E  .X  iJ! '  lijl'.'  1  .i  . ,  ''  I 

equency/Net  ID  ' 

Manual  Entry 


Line  1 .  Not  Entered 


Eigure  50.  Rapid  Request  Line  1  Prior  to  User  Input 
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Rapid  Request 


elcome  Line  1  Line . 

Unit  Name/POC 


POC  Name:  sergeant  smith 


Option  1 :  Use  Application  Presets 


Saved  Unit 

1st  Platoon,  A  1/3 

Saved  Frequencv/Net  ID 

FI  68 

Click  to  Use  Presets 


Option  2:  Manual  Entry 


Example:  1st  Platoon,  A  m 
Frequency/Net  ID  Example:  F  23 


Line  1 : 1  st  Platoon,  A  ^  /3, 
Frequency/Netid  -  FI  68,  POC  - 
_ Sergeant  Smith _ 


Figure  5 1 .  Rapid  Request  Line  1  After  User  Input 
c.  Line  2:  Precedence 

The  purpose  of  line  2  is  to  identify  how  important  the  requested  support  is  to  the 
unit’s  mission.  This  helps  higher  headquarters  prioritize  a  response.  The  screen  breaks 
down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Routine”  Radio  Button,  This  button  is  selected  by  the  user  to 
indicate  that  the  request  is  routine  in  nature  and  not  an  emergency.  The  user  should 
expect  prosecution  of  the  request  within  72  hours. 

(4)  “Priority”  Radio  Button,  This  button  is  selected  by  the  user  to 
indicate  that  the  request  should  be  a  priority  of  the  supporting  headquarters  and  support  is 
mission  critical.  The  user  should  expect  prosecution  of  the  request  within  24  hours. 

(5)  “Emergency”  Radio  Button,  This  button  is  selected  by  the  user  to 
indicate  that  support  is  needed  as  soon  as  possible  and  that  lack  of  immediate  response 
will  result  in  mission  failure. 
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(6)  Line  2  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  pressing  any  of 
the  radio  buttons,  the  color  changes  from  red  to  green. 
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Rapid  Request 


line!  Line  2  Line  3 

Precedence 


^  Routine 
Priority 
Emergency 


Line  2:  Routine 


Figure  53.  Rapid  Request  Line  2  After  User  Input 
d.  Line  3:  Type  of  Request 

The  purpose  of  line  3  is  to  indicate  what  type  of  request  follows.  The  input  to  this 
screen  potentially  generates  additional  lines  for  the  user  to  populate,  as  described  below. 
The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Resupply”  CheckBox.  This  box  is  checked  by  the  user  to 
indicate  the  he  needs  some  form  of  resupply  of  materials.  Clicking  on  the  text  displays  a 
definition  of  the  term.  Checking  this  box  will  allow  the  user  to  generate  a  line  5  of  the 
request. 

(4)  “Maintenance”  CheckBox,  This  box  is  checked  by  the  user  to 
indicate  that  he  needs  some  form  of  maintenance  support  from  higher  headquarters. 
Clicking  on  the  text  displays  a  definition  of  the  term.  Checking  the  box  will  allow  the 
user  to  generate  a  line  6  of  the  request. 
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(5)  “Vehicle  Recovery”  CheckBox,  This  box  is  checked  by  the  user 
to  indicate  that  he  needs  support  from  higher  headquarters  to  recover  a  vehicle  that  his 
unit  is  not  able  to  recover  by  itself.  Clicking  on  the  text  displays  a  definition  of  the  term. 
Clicking  on  the  box  will  allow  the  user  to  generate  a  line  7  of  the  request. 

(6)  “Engineer  Support”  CheckBox,  This  box  is  checked  by  the  user 
to  indicate  that  he  needs  some  form  of  engineering  support.  Clicking  on  the  text  will 
describe  some  of  the  services  available.  Clicking  on  the  box  ill  allow  the  user  to  generate 
a  line  8  of  the  request. 

(7)  “Pax/Cargo  Movement”  CheckBox.  This  box  is  checked  by  the 
user  to  indicate  that  he  needs  support  from  higher  headquarters  to  move  personnel  (Pax) 
or  cargo.  Clicking  on  the  text  displays  a  definition  of  the  term.  Clicking  on  the  box  will 
allow  the  user  to  generate  a  line  9  of  the  request. 

(8)  Line  3  Preview.  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  pressing  any  of 
the  checkbox  buttons,  the  color  changes  from  red  to  green.  If  all  of  the  checkboxes  are 
deselected,  the  background  color  changes  back  to  red  and  the  text  displays  as  “Line  3: 
Not  Entered.” 
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1  ^  Rapid  Request 
e ,  Line  3 

■ 

_  Type  of  Request 

***Check  all  that  apply^ 

Resupply 

Maintenance 

Vehicle  Recovery 

1^^  Engineer  Support 

il^_]  Pax/Cargo  Movement 

k _ 

1  <»t 

_  Line  3;  Not  Entered 

Figure  54.  Rapid  Request  Line  3  Prior  to  User  Input 


Figure  55.  Rapid  Request  Line  3  After  User  Input 
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e.  Line  4:  Coordinating  Instructions 

The  purpose  of  line  5  is  to  provide  timing  and  loeation  information  to  higher 
headquarters.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “As  Soon  as  Possible”  Radio  Button,  This  button  is  selected 
when  there  is  no  specific  time  the  support  is  needed.  This  lets  the  supporting  headquarters 
know  to  try  and  fulfill  the  request  as  soon  as  possible  with  no  specific  time  needed. 

(4)  “DTG”  Radio  Button,  This  button  is  selected  when  the  support  is 
needed  at  a  particular  time.  This  will  generally  be  used  when  the  support  is  needed  at  a 
specific  time  because  of  unit  movement.  For  example,  the  request  might  be  for  a  fuel 
resupply  on  a  specific  point  in  a  convoy  mission.  The  unit  commander  can  estimate  that 
the  unit  will  arrive  at  a  particular  time,  thus  minimizing  the  security  risk  to  the  refueling 
unit  due  to  loitering. 

(5)  “Use  GPS”  Radio  Button,  This  is  selected  when  the  requesting 
unit  needs  support  at  its  current  position. 

(6)  “Manual  Input”  Radio  Button,  This  is  used  when  the  support  is 
needed  at  a  location  that  is  different  that  the  unit’s  current  position.  In  the  previous 
example  of  a  refueling  request,  the  location  might  be  given  at  a  point  along  the  convoy 
route. 

(7)  “Location”  EditText,  This  field  allows  the  user  to  input  a  location 
(Latitude/Longitude  or  MGRS)  where  the  support  is  needed. 

(8)  “Other  Information”  EditText,  This  field  is  used  to  input  any 
information  about  the  request  that  is  not  included  anywhere  else  in  the  application. 

(9)  Line  4  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  selecting  both  a 
time  and  location,  the  color  changes  from  red  to  green. 
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Rapid  Request 


Coordinating  Instructions 


Time  Needed 

As  Soon  As  Possible 

DTG  OD  '  :  ^  . 


Location  Of  Request 
Use  GPS 
Manual  Input 

M.  Longi  i  MGR.'^ 


Other  Information 
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Line  4:  Not  Entered 


Figure  56.  Rapid  Request  Line  4  Prior  to  User  Input 


Figure  57.  Rapid  Request  Line  4  After  User  Input 
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f.  Line  5:  Resupply 

Line  5  will  be  available  to  populate  is  the  user  indieates  “Resupply”  as  a  type  of 
request  in  line  3.  The  sereen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Class  I”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  a  resupply  of  food  and/or  water.  A  description  of  what  is  needed  is  input  into  the 
adjacent  EditText  field. 

(4)  “Class  II”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  a  resupply  of  consumable  supplies.  The  quantity  and  description  (including 
National  Stock  Numbers  if  possible)  is  entered  in  the  adjacent  EditText. 

(5)  “Class  III”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  a  fuel  resupply.  A  description  of  the  amount  and  type  needed  is  input  into  the 
adjacent  EditText  field. 

(6)  “Class  IV”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  construction  materials.  A  description  of  the  amount  and  type  needed  is  input  into 
the  adjacent  EditText  field. 

(7)  “Class  V”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  additional  ammunition.  The  quantity  and  description  (including  Department  of 
Defense  Identification  Code  if  possible)  is  entered  in  the  adjacent  EditText  field. 

(8)  “Class  VIII”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  additional  medical  supplies.  The  quantity  and  description  (including  National 
Stock  Numbers  if  possible)  is  entered  in  the  adjacent  EditText. 

(9)  “Class  IX”  Checkbox,  This  is  selected  when  the  requesting  unit 
needs  repair  parts.  The  quantity  and  description  (including  National  Stock  Numbers  if 
possible)  is  entered  in  the  adjacent  EditText. 

(10)  Line  5  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  selecting  both  a 
category  and  description,  the  color  changes  from  red  to  green. 
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IV 
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VIII 
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ix 
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Line  5:  Not  Entered 

Figure  58.  Rapid  Request  Line  5  Prior  to  User  Input 
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Class  1  -  3  DOS  Chow/Water, 
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Figure  59.  Rapid  Request  Line  5  After  User  Input 
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g.  Line  6:  Maintenance  Contact 

Line  6  will  be  available  to  populate  is  the  user  indieates  “Maintenance  Contact” 
as  a  type  of  request  in  line  3.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Equipment  Needing  Repair”  EditText,  The  user  will  populate 
this  field  with  the  nomenclature  (and  other  information,  depending  on  unit  SOP)  of  the 
equipment  that  needs  maintenance. 

(4)  “Problem  Description”  EditText,  The  user  will  populate  this 
field  with  a  detailed  description  of  the  problem.  This  will  assist  the  supporting 
headquarters  direct  the  proper  resources/personnel  to  the  requesting  unit. 

(5)  Line  6  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
equipment  nomenclature  and  problem  description,  the  color  changes  from  red  to  green. 


IP  ^  Rapid  Request 

■  le  5  Line  6  7 

^  Maintenance  Contact 

^  Equipment  Needing  Repair 

I Li-.m-nrJatiTe  ■'  v  e 

e'l'ntnii-ti;  ’'eLPlinu'  ivD^ir 

Problem  Description 

1  <"> 

 Line  6:  Not  Entered 

Figure  60.  Rapid  Request  Line  6  Prior  to  User  Input 
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Figure  6 1 .  Rapid  Request  Line  6  After  User  Input 
h.  Line  7:  Vehicle  Recovery 

Line  7  will  be  available  to  populate  is  the  user  indicates  “Vehicle  Recovery”  as  a 
type  of  request  in  line  3.  The  screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  description. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Vehicle  Needing  Recovery”  EditText,  The  user  will  populate 
this  field  with  the  nomenclature  (and  other  information,  depending  on  unit  SOP)  of  the 
vehicle  that  needs  recovery. 

(4)  “Problem  Description”  EditText,  The  user  will  populate  this 
field  with  a  detailed  description  of  the  issue  that  resulted  in  the  need  for  recovery.  This 
will  assist  the  supporting  headquarters  direct  the  proper  resources/personnel  to  the 
requesting  unit. 

(5)  Line  7  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  Upon  populating  the 
nomenclature  and  problem  description,  the  color  changes  from  red  to  green. 
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Figure  62.  Rapid  Request  Line  7  Prior  to  User  Input 


Figure  63.  Rapid  Request  Line  7  After  User  Input 
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L  Line  8:  Engineer  Support 

Line  8  will  be  available  to  populate  is  the  user  indieates  “Engineer  Support”  as  a 
type  of  request  in  line  3.  The  sereen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  as  previous  deseription. 

(2)  Line  Title,  Same  as  previous  description. 

(3)  “Mobility”  Radio  Button,  The  user  will  select  this  radio  button  if 
he  needs  mobility  support  from  a  supporting  engineering  unit.  Mobility  includes  obstacle 
reduction  by  maneuvering  and  engineer  units  to  reduce  or  negate  the  effects  of  existing  or 
reinforcing  obstacles.  The  objectives  are  to  maintain  freedom  of  movement  for  maneuver 
units,  weapon  systems,  and  critical  supplies  [32]. 

(4)  “Counter  Mobility”  Radio  Button,  The  user  will  select  this  radio 
button  if  he  needs  counter-mobility  support  from  a  supporting  engineering  unit.  Counter¬ 
mobility  includes  the  construction  of  obstacles  to  delay,  disrupt,  and  destroy  the  enemy 
by  reinforcement  of  the  terrain  [32]. 

(5)  “Survivability”  Radio  Button,  The  user  will  select  this  radio 
button  if  he  needs  assistance  increasing  the  survivability  of  a  position  from  a  supporting 
engineering  unit.  Survivability  includes  all  aspects  of  protecting  personnel,  weapons,  and 
supplies  while  simultaneously  deceiving  the  enemy.  This  encompasses  planning  and 
locating  position  sites,  designing  adequate  overhead  cover,  analyzing  terrain  conditions 
and  construction  materials,  selecting  excavation  methods,  and  countering  the  effects  of 
direct  and  indirect  fire  weapons  [32]. 

(6)  “Horizontal  Construction”  Radio  Button,  The  user  will  select 
this  radio  button  if  he  needs  assistance  with  any  form  of  horizontal  construction  from  a 
supporting  engineering  unit.  This  includes  the  construction  required  to  shape  the  terrain 
to  meet  the  operational  requirements  of  the  unit.  The  requirements  include,  but  are  not 
limited  to:  Main  Supply  Route  (MSR)  Construction,  Expeditionary  Airfields,  Site 
Preparations  for  Static  Positions  and  Ordnance  Storage  Eacilities  [32]. 

(7)  “Vertical  Construction”  Radio  Button,  The  user  will  select  this 
radio  button  if  he  needs  assistance  with  any  form  of  vertical  construction  from  a 
supporting  engineering  unit.  Vertical  construction  is  the  improvement  or  construction  of 
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facilities  for  use  by  a  unit.  These  facilities  can  be  used  in  base  camps,  command  posts, 
and  maintenance  faeilities.  Types  of  vertieal  construction  include;  Wood  and  Masonry 
Structures,  Existing  Facility  Rehabilitation,  and  Structural  Reinforcement  [32], 

(8)  “Other”  Radio  Button,  This  is  selected  by  the  user  when  he  needs 
another  service  not  listed  in  the  five  previous  categories. 

(9)  “Support  Needed”  EditText,  The  user  will  populate  this  field 
with  a  description  of  what  service  he  needs. 

(10)  Line  8  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  neeessary  information.  Upon  seleeting  both  a 
category  and  description,  the  color  changes  from  red  to  green. 


Rapid  Request 


Engineer  Support 


Mobility 

Counter  Mobility 
'  Survivability 
Horizontal  Construction 
'  Vertical  Construction 
Other 


Support  Needed 


fn.'i.ie  .T  i  .rief  descfiijSio-  of  'he  S'jp(;'-rt 

t  I 


Line  8:  Not  Entered 


Figure  64.  Rapid  Request  Line  8  Prior  to  User  Input 
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^  Rapid  Request 


Engineer  Support 


Mobility 
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Horizontal  Construction 
Vertical  Construction 
Other 


Support  Needed 


Obstacle  reduction  IVO  Company  CP 


Lines:  MOBILITY  -  Obstacle 
reduction  IVO  Company  CP 


Figure  65.  Rapid  Request  Line  8  After  User  Input 


j.  Line  9:  Pax/Cargo  Movement 

The  purpose  of  line  9  is  provide  information  about  any  persoimel  or  cargo  that 
requires  non-organic  transportation.  The  screen  breaks  down  the  line  into  the  following 
areas: 

Navigation  Bar,  Same  as  previous  description. 

Line  Title,  Same  as  previous  description. 

“Pax”  Count,  Here,  the  user  will  indicate  the  number  of  personnel 


(1) 

(2) 

(3) 

requiring  transport. 

(4) 


“Cargo  Pounds”  EditText,  The  user  will  populate  this  field  with 
the  number  of  pounds  in  any  load  of  cargo  he  or  she  wishes  to  move. 

(5)  “Additional  Cargo  Information”  EditText,  The  user  will  select 
populate  this  field  with  amplifying  information  about  the  cargo  to  be  lifted.  This  will  help 
higher  headquarters  dispatch  the  appropriate  vehicles  and  equipment  to  move  the  cargo. 

(6)  “Destination”  EditText,  The  user  will  populate  this  field  with  a 
location  for  the  personnel  or  cargo  to  be  delivered. 
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(7)  Line  9  Preview,  Initially  this  has  a  red  background  to  indicate  to 
the  user  that  he  is  not  done  completing  the  necessary  information.  The  required  fields 
for  this  line  are  a  destination  and  number  of  pax  and/or  cargo  weight  and  description. 
Upon  populating  the  required  information,  the  color  changes  from  red  to  green. 
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Figure  66.  Line  9  Prior  to  User  Input 
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Figure  67.  Rapid  Request  Line  9  After  User  Input 

k.  Final  9-Line 

The  purpose  of  the  final  line  is  to  provide  the  user  with  a  chance  to  review  his  or 
her  inputs  and  send  the  request  by  his  or  her  preferred  method  (digital  or  voice).  The 
screen  breaks  down  the  line  into  the  following  areas: 

(1)  Navigation  Bar,  Same  description  as  previous. 

(2)  Line  Title,  Same  description  as  previous. 

(3)  Line  Description,  Instructs  the  user  to  review  the  information  in 
the  9-Line  and  press  the  “Digital”  button  to  transmit  digitally  or  “Voice”  button  to 
display  the  voice  transmission  format. 

(4)  Line  Data,  This  is  the  plaintext  version  of  the  user’s  input  that  was 
used  to  populate  the  lines.  This  is  in  plain  English  vice  line  data  format  for  ease  of  review 
by  the  user.  The  data  is  properly  formatted  prior  to  digital  transmission  or  display  to  the 
user  for  voice  transmission. 
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(5)  “Digital”  Image  Button.  This  puts  some  connectivity  information 
and  line  data  into  an  array  for  transmission  to  the  sender’s  higher  headquarters.  The 
information  is  sent  as  a  string  array  containing  the  following: 

•  Index  0:  The  string  “RAPIDREQUEST.”  The  distant  end  uses  this 
string  for  identifying  what  type  of  message  is  being  received. 

•  Index  I:  String  containing  the  plaintext  unit  title  to  inform  the 
supporting  headquarters  from  whom  the  Rapid  Request  is 
originating. 

•  Index  2:  String  containing  the  Internet  protocol  (IP)  address  of  the 
sending  device.  This  is  used  for  the  distant  end  to  acknowledge 
receipt. 

•  Index  3:  String  containing  line  1. 

•  Index  4:  String  containing  line  2. 

•  Index  5:  String  containing  line  3. 

•  Index  6:  String  containing  line  4. 

•  Index  7:  String  containing  line  5. 

•  Index  8:  String  containing  line  6. 

•  Index  9:  String  containing  line  7. 

•  Index  10:  String  containing  line  8. 

•  Index  1 1 :  String  containing  line  9 

(6)  “Voice”  Image  Button,  This  button  displays  the  9-Eine  in  proper 
format  for  digital  transmission.  This  is  used  when  there  is  no  data  network  connectivity. 

(7)  Final  9-Line  Indicator.  Initially  this  has  a  red  background  to 
indicate  to  the  user  that  he  has  not  transmitted  the  9-Eine  to  his  higher  headquarters. 
Upon  pressing  the  “Digital”  button,  the  application  transmits  the  data  array  to  the  IP 
address  and  port  as  indicated  in  the  preset  settings.  Upon  receipt  by  the  user’s  higher 
headquarters,  an  acknowledgement  message  is  sent  back  and  the  background  color 
changes  to  green  and  the  text  changes  to  “Acknowledged  By  Server.” 
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Figure  68.  Rapid  Request  9-Line  Review 
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Figure  69.  Rapid  Request  Voiee  Format 
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Figure  70.  Rapid  Request  Final  9-Line  After  Digital  Transmission 


no 


IV.  TESTING  AND  DEVELOPMENT 


A.  OVERVIEW  OF  TESTING 

We  chose  to  test  only  the  CASEVAC  application  instead  of  all  three  applications 
that  make  up  the  entire  HELP  suite  of  applications.  The  reason  for  testing  just  the 
CASEVAC  application  was  to  focus  our  limited  time  and  energy  on  getting  the  best 
design  for  one  application  which  flows  through  the  other  three  applications.  Most  design 
issues  discovered  in  the  CASEVAC  application  would  easily  translate  to  the  other 
applications  as  all  three  applications  are  very  similar  in  design.  Another  reason  we 
decided  to  test  the  CASEVAC  application  is  because  it  provides  the  best  proof  of  concept 
for  a  hand-held  device  used  to  request  support  in  stressful  conditions.  Of  all  three  of  our 
applications,  the  users  of  the  CASEVAC  application  would  be  under  most  stress;  the 
speed  and  accuracy  with  which  users  can  submit  the  MEDEVAC  9-Line  request  could  be 
the  difference  between  life  and  death. 

B,  APPLICATION  PURPOSE  AND  GOAL  REMINDER 

1.  Purpose 

The  overall  purpose  of  our  CASEVAC  application  is  to  enable  a  user  of  any  skill 
level,  in  a  stressful  environment,  to  correctly  submit  a  Medical  Evacuation  9-Line  request 
to  the  appropriate  higher  headquarters  in  a  quick  and  efficient  manner. 

2,  Goals 

The  individual  goals  of  the  CASEVAC  application  are  listed  below: 

•  Easy  enough  that  an  individual  needs  minimal  to  no  training  before  using 
the  application. 

•  Help  guide  and  direct  the  user  through  the  process  by  providing  helpful 
hints  and  shortcuts  when  filling  out  the  9-Line  information. 

•  Make  use  of  built-in  sensors  to  speed-up  the  process  of  completing  the 
request. 

•  Assist  the  user  in  submitting  the  request  even  if  there  is  no  connection  or 
digital  connection  to  higher  units. 
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•  Prevent  common  user  errors. 

C.  USABILITY  TESTING  AND  DATA  COLLECTION 

1.  Testing  Phases 

We  took  a  phased  approach  to  testing  the  CASEVAC  application  instead  of 
conducting  the  very  first  test  in  a  realistic  environment  with  simulated  casualties.  We 
broke  the  testing  down  into  three  separate  phases  (initial,  intermediate,  field)  and  we 
completed  the  first  two  tests  but  did  not  get  the  opportunity  to  do  the  third  test  because  of 
time  constraints.  The  phases  of  testing  are  as  follows: 

a.  Initial  Test 

The  purpose  of  this  test  was  to  determine  the  best  design  layout  for  the 
CASEVAC  application  and  how  to  prevent  errors  by  the  user  under  non-stressful 
conditions  and  identify  areas  in  the  user  interface  for  improvement  and  redesign. 

b.  Intermediate  Test 

The  purpose  of  this  test  was  to  evaluate  the  ease  of  use  and  the  effectiveness  of 
the  CASEVAC  application  when  a  user  is  exposed  to  low  to  medium  levels  of  stress  in  a 
laboratory  environment  and  identify  areas  in  the  user  interface  for  redesign.  Testing  was 
also  done  to  determine  the  size  of  the  data  packet  that  was  sent  from  the  application  to  the 
server. 


c.  Field  Test 

The  purpose  of  this  test  is  to  discover  the  effectiveness  and  efficiency  of  the 
application  and  the  user’s  satisfaction  with  the  application  in  a  high  stress  environment  in 
which  the  application  would  be  used.  This  test  should  to  be  conducted  in  an  environment 
similar  to  an  Infantry  Immersion  Trainer  in  which  the  user  is  exposed  to  as  realistic 
conditions  as  possible  to  test  the  CASEVAC  application  against  traditional  means  of 
submitting  a  MEDEVAC  request. 
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2. 


Data  Collection  Methods 


For  the  two  tests  that  we  condueted  the  means  for  data  eolleetion  was  very 
similar.  In  the  initial  test  we  used  a  combination  of  on-site  observation  and  two  survey 
questionnaires  to  capture  qualitative  data.  For  quantitative  data,  we  used  code  within  the 
application  to  record  the  time  the  user  spent  on  each  screen,  their  navigation  sequence, 
total  clicks,  and  the  total  time  to  complete  the  MEDEVAC  request.  Eastly,  we  used 
WireShark  to  capture  data  packets  to  determine  the  size  of  the  transmission  by  the 
CASEVAC  application  to  the  server. 

Survey  1  (Appendix  D)  contained  a  total  of  20  questions  broken  down  into 
4  categories  to  collect  qualitative  data.  The  categories  were:  Appearance,  Ease  of  Use, 
Error  Handling,  and  Overall  Impression.  The  users,  after  using  the  CASEVAC 
application,  answered  each  question  using  a  simple  Eikert  scale  from  1-5  (1-Strongly 
Disagree  and  5-Strongly  Agree).  Survey  2  (Appendix  C)  contained  5  questions  to  get 
basic  information  from  the  user  and  7  short  answer  questions  to  get  more  detailed 
feedback  about  the  application  from  the  user. 

3.  Android  Device  Used 

The  Android  device  that  was  used  in  the  first  two  testing  phases  was  the  Samsung 
Galaxy  Nexus,  which  was  released  in  2011  for  a  cost  of  approximately  $700.00; 
however,  three  years  later  the  device  is  selling  for  around  $120.  Other  key  specifications 
of  the  device  are  shown  in  Table  1  [33],  [34]. 
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Samsung  Galaxy  Nexus  Key  Specifications 

Display  Screen 

4.65  in. 

Weight 

5.1  oz. 

Operating  System 

4.0  Ice  Cream  Sandwich  (released 
Oct/2011) 

Battery  Life 

Approximately  6  days  stand  by,  12  hours 
talk 

Form  Factor 

Touchscreen 

Camera 

Front  and  Rear 

Connectivity 

802.11,  Bluetooth 

Central  Processing  Unit  (CPU) 

1.2GHz  Dual-core,  OMAP,  TI 

Ruggedized 

No 

Table  1.  Samsung  Galaxy  Nexus  Key  Speeifications,  after  [31] 


This  phone  was  chosen  for  two  reasons.  First,  the  phone  was  cheap.  The  second 
reason  was  that  we  wanted  to  prove  that  the  application  did  not  need  a  high-end  device  to 
run.  Currently,  Android  is  using  4.4  Kit  Kat  operating  system,  which  is  the  fifth  update  to 
its  operating  system  since  the  Galaxy  Nexus  was  released  [35].  We  wanted  to 
demonstrate  that  a  cheap,  older  smartphone  considered  to  be  out-of-date  is  still  capable  of 
meeting  the  military’s  needs. 

D.  INITIAL  TEST 

The  initial  testing  focused  on  the  layout  and  error  prevention  in  the  CASEVAC 
application.  The  testing  set-up  and  users’  background  for  the  initial  testing  are  discussed 
below. 


1.  Testing  Set-Up  Round  1 

For  this  test,  all  users  were  given  a  five-minute  demonstration  of  the  basic 
functions  of  the  phone,  and  how  to  navigate  the  HELP  Settings  and  CASEVAC 
applications.  After  the  demonstration  the  users  were  given  a  two-page  scenario 
(Appendix  A)  and  were  required  to  complete  a  MEDEVAC  9-Line  request  based  on  the 
information  provided  in  the  scenario.  After  they  completed  the  task  of  submitting  the 
MEDEVAC  9-Line  request  with  the  CASEVAC  application  they  were  given  two  surveys 
to  fill-out.  It  took  approximately  30  minutes  per  user  to  complete  the  test. 
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2,  Users’  Background  Round  1 

While  the  end  target  users  are  junior  serviee  members  with  little  to  no  training  on 
MEDEVAC  9-Eine  request,  the  opportunity  and  aeeess  to  those  individuals  during  this 
phase  did  not  exist.  However,  with  the  Initial  Test  foeusing  on  ease  of  use  and 
appearanee,  this  was  not  a  big  problem  with  the  population  available  at  the  Naval 
Postgraduate  Sehool.  Many  of  the  students  here  have  very  similar  eharaeteristies  that  are 
important  in  testing  the  applieation.  The  most  important  characteristics  both  groups  share 
are  that  some  members  have  experience  with  MEDEVAC  9-Eine  requests  while  others 
do  not.  The  key  to  selecting  the  individuals  for  the  Initial  Test  was  to  ensure  we  had 
individuals  with  various  skill  levels  on  MEDEVAC  requests. 

We  tested  with  a  total  of  four  individuals  for  this  phase  drawn  from  every 
service  but  the  Air  Eorce.  They  had  a  range  of  time  in  service  between  6-18  years  with 
the  average  being  12  years.  Their  self-proclaimed  experience  level  on  MEDEVAC 
9-  Eine  request  the  average  was  3.5  on  a  scale  of  I  to  5,  which  is  a  little  above  formal 
training. 


3.  Initial  Test  Results  Round  1 

The  timing  and  survey  results  from  initial  testing  for  Round  1  are  provided  below. 

a.  Time 

While  the  total  time  to  complete  the  MEDEVAC  request  was  not  the  main 
objective  of  this  phase,  we  recorded  the  time  to  complete  the  request  using  the 
application  with  a  stop  watch.  We  started  the  time  when  the  user  opened  the 
CASEVAC  application  and  stopped  the  watch  when  the  users  reached  the  “submit 
screen.”  During  the  Initial  Testing  Phase  we  saw  an  average  of  165  seconds  with  a  range 
of  118-197  seconds. 
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b.  Survey  1  Results  Round  1 

Figure  71  shows  the  total  score  for  Survey  1,  which  the  average  score  was 
94.75  out  of  100.  Figure  72  shows  the  average  score  for  the  four  different  categories  in 
Survey  1. 


Survey  1  Total  Score,  Round  1 

■  Average  ■  User  4  ■  User  3  ■  User  2  BUserl 


Figure  71.  Survey  1  Total  Score,  Round  1 


Figure  72.  Survey  1  Individual  Category  Scores,  Round  1 
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c.  Survey  2  Results  Round  1 

Selected  comments  from  Survey  2  in  Round  1 : 

(1)  Liked  features- 
“Autofdl  in  ...” 

“Easy  to  quickly  move  through  required  data  entry” 

(2)  Disliked  features- 
“Increment  button  [was]  a  little  too  close” 

“it  was  a  little  hard  to  see  the  default  information  to  enter  of  the  initial 
screen  [HELP]” 

“Needs  more  separation  between  fields  in  Lines  1  and  2. . .” 

(3)  Need  to  add  to  application- 
“Reset  form  button” 

“Need  to  increase  the  size  of  the  total  number  of  casualties  to  reference 
when  filling  out  line  5 . . .” 

“Camera  is  a  great  idea  since  there  is  some  difference  of  opinions  in 
classifying  casualties” 


E,  ANALYSIS  AND  REDESIGN  AFTER  INITIAL  TEST,  ROUND  1 

The  analysis  of  Round  1  testing  and  redesign  implemented  based  off  of 
observation  and  user  feedback  are  discussed  below. 

1.  Analysis 

Overall,  the  system  results  were  positive  and  provided  valuable  feedback.  We  had 
an  average  of  4  on  the  Likert  scale  in  all  categories  for  Survey  1.  However,  the  most 
important  feedback  that  we  received  was  from  the  comments  on  Survey  2.  The  comments 
gave  us  areas  in  the  application  that  the  layout  or  graphics  could  be  adjusted  to  make  the 
application  more  user  friendly.  Lurthermore,  several  ideas  for  adding  functionality  were 
suggested  that  we  did  not  originally  consider  during  development.  Linally,  completion 
times  between  individuals  with  different  experience  levels  were  relatively  close,  which 
shows  that  the  CASEVAC  application  is  able  to  be  used  independent  of  experience  level. 
Linally,  even  with  the  positive  feedback,  we  felt  that  at  least  another  round  in  the  Initial 
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Test  was  needed  sinee  the  pool  of  users  was  small  and  to  test  the  areas  that  we 
redesigned. 


2.  Redesign 

Beeause  of  the  overall  positive  feedbaek  from  the  users  we  deeided  that  we  were 
not  going  to  make  any  major  ehanges  to  the  design  of  the  applieation,  but  integrate  some 
of  the  layout  modifieations  that  the  users  suggested.  These  ineluded  enlarging  several  of 
the  buttons  on  various  sereens  and  an  inerease  in  font  size  on  multiple  sereens. 
Furthermore,  after  observing  the  users  during  the  tests,  we  deeide  it  would  be  best  to  add 
in  haptie  feedbaek  into  the  applieation.  So  anytime  when  the  user  presses  a  button  or 
makes  a  seleetion  there  is  vibration  to  provide  feedbaek  to  the  user  that  the  button  was 
pressed. 


a.  HELP  Settings  Redesign 

It  was  suggested  that  we  redesign  the  layout  of  the  HELP  Settings  applieation 
beeause  it  was  diffieult  to  see  what  the  user  had  entered.  Keeping  this  in  mind,  we 
ehanged  the  HELP  Settings  applieation  to  inerease  the  size  of  the  text  to  make 
information  easier  to  read.  Eurthermore,  we  ehanged  the  eolor  of  the  text  when  the  users 
entered  information  to  help  make  it  easier  for  the  user  to  see.  The  before  and  after  sereen 
shots  ean  be  seen  in  Eigures  73,  74,  and  75. 
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HELP  Settings 

SETTINGS  LANDING  ZONES 


Jnit  ID:  Not  Entered 
Update  ex:  1  St  Platoon,  A  1  /I 
-requency/Net  ID;  Not  Entered 
Update  6x:  FI  23  or  1 23.40 
i^allsign:  Not  Entered 
Update  Unit  Callsign 
Higher  HQ  IP  Address:  Not  Entered 
Update  ex:###.###.###.### 
Higher  HQ  Port;  Not  Entered 
Update  ex:  ####  or  ##### 


Clear  Settings 


<1) 


Figure  73.  HELP  Settings  Prior  to  Redesign 


HELP  Settings 

SETTINGS  LANDING  ZONES 


Unit  ID: 

Not  Entered 

Update  ex:  1  St  Platoon,  A  1  /I 

Frequency/Net  ID: 

Not  Entered 

Update  ex:  FI  23  or  1 23.40 

Callsign: 

Not  Entered 
Update  Unit  Callsign 

Higher  HQ  IP  Address: 

Not  Entered 

Update  ex:  ###.###,###.### 

Higher  HQ  Port: 

Not  Entered 

Update  ex:  ####  or  ##### 
Clear  Settings 


Oi 


Figure  74.  HELP  Settings  After  Redesign 
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HELP  Settings 

SETTINGS  LANDING  ZONES 


Unit  ID; 

1st  Platoon,  A  1/1 
Update  ex:  1st  Platoon,  A  1/1 

Frequency/Net  ID: 

FI  23 

Update  ex:  FI  23  or  123.40 

Callsign: 

Dragon  64 

Update  Unit  Callsign 

Higher  HQ  IP  Address: 
172,20.134,145 
Update  ex:  ###.###.###.### 

Higher  HQ  Port: 

4445 

Update  ^x;  ####  or  ##### 


Clear  Settings 


Figure  75.  HELP  Settings  After  User  Input 


b.  Screen/Line  1  GPS  Button  Redesign 

During  observation  we  noticed  that  some  of  the  users  seemed  to  search  for  the 
GPS  button  on  Screen/Line  1  of  the  MEDEVAC  request.  In  order  to  reduce  the  time 
needed  to  find  the  button  we  made  the  GPS  button  larger  to  take  up  more  screen  space. 
The  before  and  after  screen  shots  can  be  seen  in  figures  76  and  77. 
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O  CASEVAC 


LINE  1  LINE  2 

Landing  Zone  Location 


Enter  a  location  for  the  landing  zone.  Alternatively,  you 
may  use  your  device's  GPS. _ 


Option  2:  Manual  Lat/Long  Entry 


_ _  Latitude 

Longitude 

Use  Manual  Lat/Long  Input 


Line  1 :  Not  Entered 


Figure  76.  CASEVAC  Line  1  Before  Initial  Redesign 


O  CASEVAC 

LINEl  LINE  2 

Landing  Zone  Location 


Enter  a  location  for  the  landing  zone.  Alternatively,  you 
I  may  use  your  device's  GPS. _ 


Option  1 :  Use  Device  GPS 


Use  GPS 


Option  2:  Manual  Lat/Long  Entry 


_ .Latitude 

Longitude 

Use  Manual  Lat/Long  Input 


Line  1 :  Not  Entered 
Ecp  CTIa 


Figure  77.  CASEVAC  Line  1  After  Initial  Redesign 
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c.  Screen/Line  2  Preset  Button  Redesign 

During  observation  and  feedback  provided  by  the  users,  we  determined  that  the 
preset  button  on  Screen/Line  2  had  the  same  problem  as  the  GPS  button  on  Line  1. 
Again,  we  increased  the  size  of  the  button  to  take  up  more  screen  real  estate  to  make  it 
easier  to  find.  Furthermore,  we  moved  the  saved  preset  information  above  the  preset 
button,  to  help  draw  the  user’s  eyes.  The  before  and  after  screen  shots  can  be  seen  in 
Figures  78  and  79. 


O  CASEVAC 

LINEl  LINE  2  LINES 

Frequency/Callsign 


I  Enter  your  unit  contact  Irequency  and  callsign.  | 


Option  1 :  Use  Application  Presets 


Saved  Frequency:  FI  23 

Use  Presets 

Saved  Callsign;  Skeeter  65 


Line  2:  Not  Entered 
<“3 


Figure  78.  CASEVAC  Line  2  Prior  to  Initial  Redesign 


122 


O  CASEVAC 

.INEl  LINE  2  LINES 

Frequency/Callsign 


I  Enter  your  unit  contact  frequency  and  callstgn.  | 


Option  1 :  Use  Application  Presets 


Saved  Frequency;  FI  23 
Saved  Callsign;  Dragon  64 


Use  Presets 


Line  2:  Not  Entered 


Figure  79.  CASEVAC  Line  2  After  Initial  Redesign 
d.  Screen  1 0/Final  Review  Redesign 

Like  the  previous  two  changes,  the  “Send  to  Higher  Headquarters”  button  was 
determined  to  be  too  small  based  on  feedback  and  observation  and  that  it  should  be  made 
larger.  We  increased  the  size  of  the  button  to  make  it  take  up  more  real  estate  on  the 
screen  to  make  it  easy  to  see  and  press.  The  before  and  after  screen  shots  can  be  seen  in 
Figures  80  and  81. 
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REVIEW 


O  CASEVAC 
LINE  9 

FINAL  9-LINE 


Please  review  the  following  9-Lrne.  If  It  is  correct, 
press  the  button  to  send  to  higher  headquarters. 

Line  1:  MGRS  18SAE456278 

Line  2:  Frequency  FI  23,  Callsign 

Skeeter  65 

Line  3:  A  -  3,  B  - 1 

Line  4:  A 

Lines:  L- 2,  A- 2 
Line  6:  N 

Line  7:  E  -  IR  BUZZSAW 
Line  8:  A  -  3,  D  - 1 
Line  9:  None 


Send  to  Higher  Headquarters 


Final  9-Line  Not  Sent 


Figure  80.  CASEVAC  Final  Review  Screen  Prior  to  Initial  Redesign 


O  CASEVAC 
JNE  9  REVIEW 

FINAL  9-LINE 


Please  review  the  following  9*Line.  If  it  is  correct, 
press  the  button  to  send  to  higher  headquarters. 

Jne  1:  MGRS  18SAE1 34589 

-ine  2:  Frequency  FI  23,  Callsign  Dragor 

54 

Jne3:A-2,  B  -  1 
-ine  4:  B 

jne5:L-  l,A-2 
.ine  6:  N 
.ine  7:  A 
.ine  8:  A  -  3 
.ine  9:  None 


Send  to  Higher 
Headquarters 


Final  9-Line  Not  Sent 


Figure  8 1 .  CASEVAC  Final  Review  After  Initial  Redesign 
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F.  TEST  SET-UP  INITIAL  TEST,  ROUND  2 

For  Round  2  in  the  Initial  Test  all  users,  which  were  different  from  Round  1, 
where  given  the  same  five  minute  demonstration  on  basic  functions  of  the  phone,  and 
how  to  navigate  the  HELP  Settings  and  CASEVAC  applications  as  in  Round  1 .  After  the 
demonstration  the  users  were  given  the  same  two  page  scenario  (Appendix  A)  and  were 
required  to  complete  a  MEDEVAC  9-Line  request  based  on  the  information  provided  in 
the  scenario.  After  they  completed  the  task  of  submitting  the  MEDEVAC  9-Line  request 
with  the  CASEVAC  application  they  were  given  two  surveys  to  answer.  In  Round  2  we 
wanted  to  capture  more  data  than  in  the  first  round.  To  do  this  we  implemented  code 
within  the  CASEVAC  application  to  capture  the  number  of  keystrokes  (Eigure  82),  and 
the  time  spent  on  each  screen.  This  additional  information  helped  highlight  areas  within 
the  application  that  could  be  improved,  which  could  not  be  captured  by  surveys  or 
observation.  The  total  time  to  test  each  user  took  approximately  30  minutes. 


c 

)  CASEVAC 

A 

• 

A 

INE 

©  Results  3 

1 

Sere 

butt 

Line  0:  4.613  Seconds 

Line  1:  6.162  Seconds 

Line  2:  7.008  Seconds 

1 

disp 

Line  3:  8.684  Seconds 

.ine 

Line  4:  2.71  Seconds 

Line  5;  3.1 56  Seconds 

Line  6:  2.699  Seconds 

.ine 

Line  7:  2.971  Seconds 

gc 

.ine 

Line  8:  2.536  Seconds 

Line  9:  2.992  Seconds 

.ine 

Final  Review:  13  281  Seconds 
Total  Button  Clicks=14 

Nc 

Jpe 

.ine 

’ati 

lit 

voice 

Eigure  82.  CASEVAC  Testing  Result  Example 
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1. 


Users’  Background  Round  2 


Like  Round  1,  we  were  not  able  to  get  access  to  junior  service  members,  but 
relied  on  students  (military  and  civilian)  at  NFS.  In  addition,  we  doubled  our  number  of 
users  to  test  the  application  for  this  round.  Their  average  self-proclaimed  experience  level 
on  MEDEVAC-9  Eine  request  was  an  average  of  2.2,  which  is  informal  training  level 
(Eigure  83). 


User  Experience  Level,  Round  2 


■  User  Experience  Level 


Experience  Level 


Eigure  83.  User  Experience,  Round  2 


2,  Initial  Test  Results  Round  2 

The  timing  and  survey  results  from  Round  2  of  initial  testing  are  discussed  below. 

a.  Time  and  Total  Clicks 

Eigure  84  shows  the  results  for  the  average  time  spent  per  screen  by  each  of  the 
nine  users.  The  longest  time  spent  on  any  screen  was  Eine  3,  which  is  the  precedence 
level  of  the  casualties.  Eigure  85  shows  the  results  of  the  total  clicks  per  user  and  the  total 
time  to  complete  the  scenario.  The  average  for  all  users  to  complete  the  scenario  was 
150.7  seconds  or  2  minutes  and  20  seconds  with  a  range  between  72-269  seconds.  The 

average  total  clicks  were  35  with  a  range  of  29-51  clicks. 
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Average  Time  per  Line,  Rd  2 


•Average  time  spent  per 
line 


01 

cc 


Screen  Number 


Figure  84.  Average  Time  per  Line,  Round  2 


b.  Survey  1  Results  Round  2 

The  average  overall  score  for  Survey  1  was  95.89  with  a  range  93-99,  and  per 
category  range  were  4.75-5.00;  see  results  in  Figure  86  and  Figure  87. 
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Survey  1  Total  Score,  Round  2 


Total  Score 


Figure  86.  Survey  1  Total  Score,  Round  2 


Survey  1  Individual  Categories  Scores, 

Round  2 


■  Average  Appearance  ■  Average  Ease  of  Use 

■  Average  Error  Handling  ■  Average  Overall  Impression 


Figure  87.  Survey  1  Individual  Categories  Scores,  Round  2 

c.  Survey  2  Results  Initial  Testing  Phase,  Round  2: 

Selected  comments  from  Survey  2  the  users; 

(1)  Liked  Features 
“Autofdl  in  ...” 
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“displaying  one  option  line  at  a  time,  which  helps  guide  the  user  through” 
“GPS  and  pre-set  feature” 

“vibration  response  to  entering  information. . 

(2)  Disliked  Features 

“description  of  precedence  levels,  they  need  to  be  simpler” 

“easy  to  fat- finger  some  screens. . .” 

(3)  Need  to  add  to  application 
“Swipe  arrow  to  help  guide  user. . .” 

“Question  mark  to  inform  user  of  added  help” 

“ability  to  save  or  update  information  after  transmission” 

G.  ANALYSIS  AND  REDESIGN  AFTER  ROUND  2 

The  analysis  of  Round  2  testing  and  redesign  implemented  based  off  of 
observation  and  user  feedback  are  discussed  below. 

1.  Analysis 

Similar  to  Round  1,  the  test  results  for  Round  2  were  positive,  and  again,  we 
gained  valuable  feedback  from  the  nine  users.  As  before,  the  goal  for  Survey  1  was  an 
average  4  on  the  Likert  scale  which  we  easily  achieved  again  in  Round  2.  Furthermore, 
we  saw  over  half  a  point  increase  in  the  Error  Handling  category  which  helped  validate 
that  design  changes  we  made  after  Round  1.  Furthermore,  there  was  a  15  second 
reduction  in  the  time  to  generate  the  request,  which  further  validates  the  redesign  after 
Round  1.  While  the  results  from  Survey  1  were  positive,  we  were  a  little  shocked  to 
discover  that  total  clicks  did  not  have  a  stronger  correlation  between  overall  times.  While 
there  is  a  weak  correlation  with  total  clicks,  we  expected  there  to  be  a  strong  correlation 
with  the  longest  times  being  the  ones  with  the  most  clicks,  which  was  not  the  case 
(Figure  85).  For  example  we  had  three  users  with  a  total  of  42  clicks  but  their  times 
ranged  from  95.7  seconds  to  212.0  seconds,  which  translated  into  the  second  fastest  time 
and  the  third  slowest  time.  There  are  also  several  cases  of  fewer  total  clicks  but  a  slower 
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time  compared  to  more  total  clicks  and  faster  time.  While  these  results  were  unexpected, 
we  cannot  determine  at  this  time  with  the  information  collected  why  this  is  the  case. 

Overall,  the  result  from  Survey  1  and  Survey  2  show  that  the  CASEVAC 
application  is  feasible  and  applications  can  be  used  to  call  in  requests  for  services.  After 
the  results  from  this  round  we  felt  that  we  could  proceed  to  the  Immediate  Test. 

2,  Redesign 

We  chose  to  focus  on  two  comments  that  appeared  numerous  times  in  Survey  2: 
“fat  lingering”  and  “guiding  the  user.”  We  felt  that  focusing  on  these  two  areas  after 
Round  2  would  give  us  the  greatest  improvement  to  the  CASEVAC  application  at  this 
time. 


a.  Line  3/5/8  Redesign  to  Prevent  “fat-fingering” 

Selecting  the  wrong  button  or  also  known  as  “fat  lingering”  is  always  going  to  be 
a  challenge  with  any  application  on  a  smart  device  because  of  the  limited  screen  real 
estate,  and  with  our  application  we  have  to  take  stress  into  consideration.  In  order  to  try 
to  help  eliminate  “fat  lingering,”  we  have  decided  that  in  almost  every  screen  there  is  text 
that  can  be  eliminated  to  free  up  screen  real  estate.  Eor  example;  on  Eine  3,  we  removed 
the  top  line  that  gave  directions  to  the  user  and  we  removed  the  radio  abbreviations  (A- 
Urgent,  etc.)  to  make  room  for  the  buttons  to  be  larger.  (Eigures  88-91)  Another 
improvement  to  reduce  the  issue  of  “fat  lingering”  is  adjusting  the  layout  of  the  buttons. 
Before,  all  buttons  were  on  the  left  side  of  the  screen  and  the  same  color.  We  moved  the 
location  of  the  buttons  so  they  are  not  located  next  to  each  other  and  provided  as  much 
space  as  possible  between  the  two.  Next,  we  color  coded  the  buttons  to  provide  a  greater 
distinction  between  the  two  to  help  eliminate  accidental  selection  of  the  wrong  button. 
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OCASCVAC 

IS€3 

Precedence 

^  -»•#»  Vf  *fT» 

2 

A  -  Urgent 

'  1 

B  -  Urgent  Surgical 

0 

C  -  Priority 

\ 

D  -  Routine 

0 

E  -  Convenience 

1  Lt'v3  A  2  B- 1.D- 1  1 

Figure  88.  CASEVAC  Line  3  Prior  to  Redesign 


O  CASEVAC  ; 

IINE2  LINE  3  LINE  4 

Casualties  by  Precedence 

O 

0  Q  Urgent 

o 

0|  Urgent  Surgical 

o 

0  Priority 

o 

0  ^  Routine 

o 

0  ^  Convenience 

Line  3:  Not  Entered 

Figure  89.  CASEVAC  Line  3  After  Redesign 
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Figure  90.  CASEVAC  Line  5  Prior  to  Redesign 


O  CASEVAC 


Number  of  Patients  By  Type 


NOTE:  You  previously  indicated  in  LINE  3  that 
there  are  a  total  of  2  casualties. 


Q  2  Q  Litter 


Ambulatory 


Line  5:  L  -  2 


Figure  91 .  CASEVAC  Line  5  After  Redesign 
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b.  Guiding  the  User 

The  testing  brought  to  our  attention  that  some  users  may  not  know  how  to 
navigate  through  the  applieation,  or  may  need  definitions  to  help  them  guide  in  their 
deeision  making.  To  eliminate  this,  we  added  an  additional  screen  at  the  beginning  of  the 
application.  This  screen  is  the  first  screen  that  user  will  see  when  the  application  is 
launched.  It  provides  the  user  with  basic  instructions  on  how  to  navigate  through  the 
application  and  also  that  there  are  definitions  to  help  guide  them.  We  believe  after  using 
the  application  a  few  times  or  if  the  application  comes  with  a  training  program  that  this 
screen  could  be  eliminated.  Until  then,  the  “Welcome”  screen  will  be  needed  for  users 
who  are  unfamiliar  with  the  application. 


O  CASEVAC 


INTRODUCTION  LINE  I 

Welcome 


Access  the  settings  at 
the  top  right. 


t 


Use  your  finger  to 
swipe  between  lines. 


Click  on  unfamiliar 
terms  to  get  a 
definition. 


Figure  92.  CASEVAC  Welcome  Screen 


c.  Redesign  of  the  Final  Review  Screen 

Upon  reviewing  the  time  spent  per  screen  by  the  users,  we  noticed  that  the  users 
spent  a  lot  less  time  than  expected  reviewing  their  request  before  submitting.  After  some 
analysis,  we  was  determined  the  “review”  screen  was  too  complex  and  provided  little 
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information  to  an  untrained  user.  It  was  too  eomplex  beeause  we  were  trying  to  eombine 
the  final  review  and  the  baek-up  means  of  submitting  the  request  on  the  same  sereen.  The 
information  presented  to  the  user  is  what  would  need  to  be  read  to  submit  the  request  via 
voiee;  however,  presenting  the  information  this  way  did  not  give  any  reviewable 
information  to  an  untrained  user.  This  is  because  an  urgent  casualty  is  transmitted  over 
the  radio  A-1,  and  an  untrained  user  would  not  know  what  “A-1”  meant.  To  correct  this 
issue  the  “review”  screen  was  redesigned  to  allow  the  user  to  review  their  request  in  plain 
language  terms  vice  brevity  codes.  Now,  there  is  an  additional  transmit  button  that  will 
allow  the  user  to  display  the  voice  format.  If  the  user  selects  “digital”  the  application  will 
function  in  the  exact  same  way  before  the  redesign,  which  is  sending  a  request  in  the 
proper  format  digitally  to  the  server.  However,  if  the  user  selects  “voice,”  a  pop-up 
screen  will  appear  with  the  correct  format  needed  to  properly  transmit  the  request  over 
the  radio. 


Figure  93.  CASEVAC  Final  Review  Prior  to  Final  Redesign 
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REVIEW 


O  CASEVAC 


FINAL  9-LINE 


Scroll  through  to  review  the  9*Line.  Press  either  the 
digital  button  to  send  digitally  or  the  voice  button  to 
display  the  voice  format, _ 

Line  1:  MGRS  18  ABC  123  456 


Line  2  (Frequency/Callsign): 

Frequency  -  FI  23,  Callsign  -  NFS  Demo 

Line  3  (Casualties  by  Precedence): 

1  Urgent 

Line  4  (Special  Equipment  Needed): 


Digital 


Voice 


Final  9-Line  Not  Sent 


Figure  94.  CASEVAC  Final  9-Line  After  Final  Redesign 


O  CASEVAC 

line]  Voice  Format 


□  I 


[Higher  HQ  Callsign),  this  is  NFS 
Demo ;  Stand  by  for  CASEVAC 
Request. 

Line  1:  MGRS  18A  BC  123  456 

Line  2:  Frequency  FI  23,  Callsign 

NFS  Demo 

Line  3:  A  - 1 

Line  4:  A 

Line  5:  L  - 1 

Line  6:  N 

Line  7:  A 

Line  8:  A  - 1 

Line  9:  None 


Digital 


Final  9-Line  Not  Sent 


Figure  95.  CASEVAC  Voice  Transmission  Format 
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3. 


WireShark  Testing 


After  several  redesigns  of  the  CASEVAC  application,  we  wanted  to  determine  if 
improvement  to  the  user  interface  or  the  data  packet  would  give  us  the  greatest  benefit  in 
increasing  the  efficiency  of  the  application.  WireShark  was  utilized  to  capture  the 
application’s  data  packet  and  conduct  the  analysis.  We  focused  on  two  packets  in 
particular  to  analyze.  The  first  packet  was  a  MEDEVAC  request  that  the  user  only 
selected  the  bare  minimum  needed  to  submit  a  request  i.e.,  only  one  casualty  and  the  bare 
minimum  per  line.  This  bare  minimum  request  only  required  310  bytes  to  transmit  the 
request.  Next,  we  maxed  out  every  field  in  the  CASEVAC  application  or  selected  as 
many  buttons  as  possible  per  line.  This  request  was  for  999  casualties  and  with  all  options 
selected,  and  this  only  required  less  than  400  bytes  to  transmit  the  request  to  the  server. 
Figures  96  and  97  represent  a  WireShark  capture  of  the  data  being  transmitted  over  the 
NFS  Wireless  Network  for  the  minimal  casualty  request. 


No.  jTime  Isource  jDestination  |  Protocol!  Length  |  Info 

eeS^fi.MailOOeO  172.^.H6.«6  172.20  146.55  TCP  74  SACK_P6W  1  TSvjI  30Q2334  TS*cr  e  WS  6<_  1 

U>;  b  S4S»l40a«  1/7. 7S  Ufa  4b  1 77  7«  Ufa  SS  fCP  fab  !b04  7  >  upnotlfyp  IA(K)  1  faCtc  1  Min:  UfaVb  I  fan  0  TSv4l  K>07  M4  IS«rr  S^niMU 

seo  6  S477na««  177  ?«. 146.46  17?  ?«  146  TCf  66  19647  >  upnolityp  I66H.  40C}  Sfapd  *i  ksl  Nins14616  Ime?  TSv4l  b160711%  TS<h  i  «11711661? 

611  6.6S337300O  172.26. 146  46  172.20.146  SS  TCP  68  39047  v  vpnetlfyp  ir>Sn.  ACK]  Ack>l  Nint>I46S6  L«n>2  rSv«l«3e0233S  TS«crs3S731001S 

632  6.S37633000  173.20.146.46  172.20.146.33  TCP  66  39047  >  upnotifyp  lACK)  S*q  3  AcK  3  HU)  14636  Lon  6  TOval  30023M  TSecr  SS7316620 

bJJ  b  ^’■/blboeo  177.70  I4fa.4b  177.70  Ufa  SS  ICP  fa7  70047  >  upAortfyp  (PSH.  ACK}  S*q  3  Aclc  S  Mia  Ubfafa  (*A  1  ISvat  lB07JNt  IVACr  337310870 

613  6  366911660  17?.  ?6  146  46  17?  76  146  33  TfO  176  10647  >  upnodlyp  163H.  AfK]  3faqa6  A<  ks3  Wins|4636  IntsIlO  TOv.tl s3e6?316  T3rcrB3371l68?4 

639  6  594342006  172.20  146  46  172.20  146  35  TCP_ 66  39047  >  opnotifyp  |ACKI  S*q»316  4cfc«49  Hu>al4656  lowO  TSv6l«3602341  TS«<r«5S7310e27 


Figure  96.  WireShark  Trace 


F 

Frame  635:  376  bytes  on  wire  {3008 

bits),  376  bytes  captured  (3008  bits)  on 

interface  0 

> 

Ethernet  II,  Src;  SamsungE  16:0a:lf  (20: 64: 32: 16: Oa: If ) ,  Dst:  Apple  78:5e:e0 

(7c:dl:c3:78:5G:G0) 

> 

Internet  Protocol  Version  4,  Src: 

172.20.146.46  (172.20.146.46),  Dst:  172.20 

. 146.55  (172. 20. 146.55) 

> 

Transmission  Control  Protocol,  Src 

Port:  39047  (39047),  Dst  Port:  upnotifyp 

(4445),  Seq:  6,  Ack:  5,  Len :  310 

> 

Data  (310  bytes) 

Figure  97.  WireShark  Packet  Capture 


4,  WireShark  Analysis 

It  was  not  a  big  surprise  that  the  data  packet  size  was  small,  but  we  were  a  little 
surprised  that  there  was  very  little  difference  between  the  smallest  request  and  the  largest 
request.  In  addition,  the  WireShark  capture  confirmed  our  belief  that  our  main  focus  at 
this  point  in  development  should  be  on  improving  the  user  interface  as  much  as  possible. 
This  is  because  the  average  time  to  generate  a  request  was  150.7  seconds.  While,  the  data 
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packet  is  extremely  small,  400  bytes  at  the  most,  trying  to  reduee  the  data  packet  at  this 
point  would  not  be  as  great  of  a  gain  as  trying  to  reduee  seconds  off  of  the  time  to 
generate  a  request. 

H.  INTERMEDIATE  TEST 

The  purpose  of  the  intermediate  phase  of  testing  was  to  evaluate  the  CASEVAC 
applieation  in  a  medium  stress  environment.  The  testing  set-up  and  users’  background  for 
intermediate  testing  are  discussed  below. 

1.  Test  Set-up 

For  this  test,  4  groups  of  an  average  of  10  users  were  given  a  30  minute 
presentation  on  MEDEVAC  procedures,  a  5  minute  demonstration  of  the  phone  and 
CASEVAC  application,  5  minutes  to  explore  the  phone  and  application,  and  a  question 
and  answer  period.  Following  the  presentation  and  demonstration,  the  users  were  divided 
into  two  groups  of  five.  Eaeh  group  was  given  the  same  two-page  seenario  that  was  used 
in  the  early  rounds  of  testing.  However,  in  one  group  eaeh  member  of  the  group  was 
given  the  Galaxy  Nexus  with  the  CASEVAC  application  on  it  to  submit  the  request.  The 
other  group  was  only  given  a  “cheat  sheet”  (Appendix  B)  with  an  outline  of  the 
CASEVAC  format  and  screen  shot  of  a  GPS  to  help  them  submit  the  request. 

In  this  phase  we  set  up  an  aeeess  point  using  a  Wave  Relay  Radio  by  Persistent 
System  (described  in  the  following  section)  in  order  to  allow  the  phone  to  submit  the 
request  to  the  server  loeated  on  a  laptop  in  the  room.  We  stopped  the  time  of  the  request 
for  the  individuals  in  the  group  with  the  phone  when  the  request  was  reeeived  on  the 
server.  For  the  group  without  the  phone  we  stopped  the  time  when  the  individual  was 
prepared  to  transmit  the  request  over  the  radio. 

2.  Wave  Relay  Radio 

The  Wave  Relay  radio  is  a  Mobile  Ad  Hoe  Networking  System  (MANET),  whieh 
allows  the  user  to  maintain  connectivity  on  the  move  and  is  similar  in  size  to  the  PRC- 
152  radio  currently  in  use  by  the  military  [36].  The  radio  has  the  ability  to  perform  push 
to  talk  (PTT)  voiee,  data  transfer,  and  video  transfer.  It  has  the  ability  for  a  layer-2 
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Ethernet  connectivity,  which  facilitates  plug-and-play  of  cameras,  IP  sensors,  video 
encoders  and  other  devices  [36].  It  can  be  used  as  a  wireless  access  point,  which  is  how 
it  was  utilized  in  our  testing.  Finally,  the  Wave  Relay  Radio  is  capable  of  throughput  of 
41  Mbps  using  UDP  and  31.1  Mbps  using  TCP.  Other  key  specifications  are  listed  in 
Table  2. 


Wave  Relay  Radio  Selected  Specifications 

Weight  w/  battery 

1 . 1  pounds 

Battery  life 

14  hours 

Size  w/  battery 

7.8  X  3.0  X  1.5  in 

Networking 

802.1  la/b/g  AP  compatible,  IPv4  and  IPv6 
compatible.  Dynamic  Fine  Exchange 
Protocol  Certified 

Security 

Utilizes  Suite  B  algorithms.  Active 
response  to  tamper,  AES-CTR-256  with 
SHA-512  HMAC,  FIPS  140-2 

Push  to  talk 

Supports  16  channels 

GPS  capable 

Yes 

Table  2.  Wave  Relay  Radio  Selected  Specifications,  after  [36] 


Figure  98.  Persistent  Systems  Wave  Relay  Radio,  from  [36]. 
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3,  Users’  Background 

During  this  test  we  were  able  to  get  aecess  to  the  target  audienee,  which  is  junior 
service  members  untrained  on  MEDEVAC  procedures.  Defense  Eanguage  Institute 
(DEI),  which  is  located  in  Monterey,  CA  only  a  few  miles  from  NFS,  provided  a  perfect 
pool  of  users  to  test  the  CASEVAC  application.  The  users  were  drawn  from  the 
group  of  junior  Marines  waiting  for  their  training  to  begin.  The  vast  majority  of  these 
Marines  have  less  than  a  year  in  the  Marine  Corps  and  no  experience  with  MEDEVAC 
procedures.  The  average  experience  level  with  MEDEVAC  procedures  for  the 
38  individuals  drawn  from  this  group  for  testing  was  1.8,  which  puts  the  average  just 
below  informal  training.  Eurthermore,  the  users’  average  rank  was  Private  First  Class  or 
E-2,  and  they  had  an  average  of  eight  months  in  the  military. 

4.  Intermediate  Test  Results 

The  timing  and  survey  results  from  the  intermediate  testing  are  discussed  below. 

a.  Time 

As  mentioned  earlier,  we  broke  the  users  into  two  equal  groups  of  19  individuals 

per  group,  one  group  used  our  CASEVAC  application  and  the  other  used  traditional 

means  to  submit  the  request.  Timing  for  this  phase  of  testing  was  recorded  differently  for 

each  group.  The  time  for  the  group  that  used  the  CASEVAC  application  started  when  the 

user  opened  the  application  and  stopped  when  the  user  submitted  the  request  to  the 

server.  This  is  no  different  than  how  time  was  recorded  earlier  for  previous  tests.  The 

time  for  the  group  that  used  the  traditional  means  of  submitting  a  MEDEVAC  request 

was  started  by  the  evaluator  and  stopped  when  the  individual  had  formulated  their  request 

and  was  ready  to  submit  the  request  via  the  radio.  The  transmission  time  was  not 

recorded  because  people  transmit  at  different  speeds  and  between  the  two  methods  the 

CASEVAC  submission  time  would  always  beat  the  traditional  means.  The  average  time 

for  the  group  using  the  traditional  method  was  25 1  seconds  to  formulate  the  request.  The 

fastest  time  to  formulate  the  request  using  traditional  methods  was  109  seconds  and  the 

slowest  was  390  seconds.  Again,  the  time  for  the  traditional  method  does  not  include  the 

transmission  time  needed  to  submit  the  request  to  higher  headquarters.  One  could  easily 
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add  on  at  least  30  seconds  to  this  time,  in  the  best-case  scenario,  to  allow  for  transmission 
of  the  request  to  higher  headquarter.  Also,  one  needs  to  consider  the  time  needed  for  the 
radio  operator  to  record  the  request  and  input  the  request  into  the  proper  chat  window. 
The  average  time  for  the  group  using  the  CASEVAC  application  was  131  seconds,  which 
included  submission  to  the  higher  headquarters.  The  fastest  time  using  the  application 
was  50  seconds  and  the  slowest  time  was  204  seconds.  The  application  group  needed  on 
averaged  120  seconds  less  to  formulate  and  submit  their  requests  compared  to  the  group 
without  CASEVAC  that  only  formulated  but  did  not  submit  their  request.  See  results  in 
the  Eigures  below. 


i 
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45.00 
40.00 
35.00 
■D  30.00 
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Average  Time  Spent  per  Line,  Intermediate 

Phase 

A 

/  \ 

/  \ 

/  \ 

/  \ 

/ 

/  >  Average  Time  Spent  per  Line 

sf"  s/  sf"  s/  s/  s/  s>V" 

Figure  99.  Average  Time  Spent  Per  Line,  Intermediate  Phase 
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Total  Time  per  User  with  CASEVAC, 
Intermediate  Phase 

ocn  n 

onn  n 

1  cn  n 

1  nn  n 

cn  n 

1 

■  Total  In  Seconds 

n  n 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

Average 

Figure  100.  Total  Time  per  User  with  CASEVAC,  Intermediate  Phase 


Total  Clicks  and  Total  Time  per  User, 
Intermediate  Phase 


I  Total  Clicks  ■  Total  Time 


203.9 
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Figure  101.  Total  Clicks  and  Total  Time  per  User,  Intermediate  Phase 
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Average  Time  with  and  without 
CASEVACin  Seconds 

■  Average  Time  using  "CASEVAC"  ■  Average  Time  w/o  "CASEVAC" 

■  Difference 


Figure  102.  Average  Time  With  and  Without  CASEVAC 
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Figure  103.  Total  Time  of  Complete  MEDEVAC  Request  Without  Application 
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b.  Survey  1  Results 

The  average  overall  score  for  Survey  1  was  93.5  with  a  range  between  78  and 
100,  and  the  per-category  range  was  between  4.60  and  4.98,  see  results  in  Figure  104  and 
Figure  105. 


Intermediate  Phase,  Survey  1  Total  Scores 


Total  Scores 


Figure  104.  Intermediate  Phase,  Survey  1  Results 
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Intermediate  Phase,  Individual 
Category  Scores 

■  Average  Appearance  ■  Average  Ease  of  Use 

■  Average  Error  Handling  ■  Average  Overall  Impression 


Figure  105.  Intermediate  Phase,  Individual  Category  Seores 


c.  Survey  2  Results 

Seleeted  eomments  from  Survey  2  in  the  immediate  testing  phase: 

(1)  Liked  features 
“GPS  Feature...” 

“The  simple  way  it  walks  you  through  eaeh  line  and  the  information  required.” 
“The  check  box  format  was  simple  and  easy  to  use.” 

“Easy  for  anyone  to  use  even  without  formal  9-line  training.” 

“The  ability  to  see  definition  for  the  terms...” 

(2)  Disliked  features 

“The  plus  sign  proximity  to  the  term  several  time  [I]  went  to  increase  a  number 
but  instead  had  the  definition  box  pop-up.” 

“Some  buttons  could  be  made  larger.” 

“The  inability  to  clear  the  app  without  closing  it.” 

(3)  Need  to  add  to  application 

“The  GPS  and  Transmit  buttons  could  be  colored.” 

“When  the  bottom  bar  turns  green,  it  should  flash  more  noticeably. . .” 

“Add  tabs  so  you  can  instantly  flip  between  any  line  in  case  you  have  to  make  a 
correction...” 

“add  ‘?’  to  the  definitions  to  show  they  contain  definitions....” 
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d. 


Error  Rate 


This  phase  of  testing  gave  us  the  opportunity  to  eompare  the  error  rates  of  the 
traditional  methods  of  submitting  a  MEDEVAC  request  (using  a  eheat  sheet  to  generate 
the  request)  against  our  CASEVAC  applieation.  Errors  in  the  MEDEVAC  request  ean 
range  from  slowing  down  proeessing  of  the  request,  to  the  possibility  of  not  soureing  the 
eorreet  number  of  evacuation  platforms,  or  even  sending  the  casualties  to  the  wrong  level 
of  treatment  facility. 

We  considered  that  every  line  in  the  request  could  be  a  possible  error,  so  a  user 
could  make  up  to  nine  errors  in  the  one  request.  Below  is  a  list  of  inputs  by  a  user,  which 
counted  towards  an  error: 

•  Obvious  wrong  precedence  level  for  a  patient,  for  example  user  selected 
“routine”  for  an  individual  with  a  missing  leg,  which  should  be  an  “urgent 
surgical.”  However,  we  did  not  consider  it  an  error  if  the  user  was  within 
one  precedence  level,  for  example  the  user  selected  “urgent”  for  a  “urgent 
surgical”  or  vice  versa. 

•  Selecting  the  wrong  special  equipment 

•  Entering  in  the  location  of  the  pick-up  site  in  wrong  format  (odd  number 
MGRS) 

•  Selecting  the  wrong  method  of  marking  for  the  pick-up  site 

•  Selecting  the  wrong  number  of  patients 

•  Selecting  the  wrong  patient  nationality 

In  this  test,  the  19  users  using  the  CASEVAC  application,  only  had  a  combine 
total  of  7  errors  out  of  a  possible  171  lines,  which  was  a  total  error  rate  of  4.1%.  The 
users  using  the  traditional  method  nearly  tripled  that  number  with  a  total  of  1 8  lines  with 
an  error  for  the  same  number  of  requests,  which  gave  the  group  a  total  error  rate  of 
10.5%.  It  should  be  mentioned  that  this  group’s  error  rate  does  not  include  transmitting 
the  request  to  the  radio  operator,  the  radio  operator  recording  the  request,  and  then 
entering  the  request  into  the  proper  chat  window,  which  will  naturally  increase  the 
probability  for  errors.  However,  with  the  CASEVAC  application,  all  the  radio  operator 
has  to  do  is  copy  the  submitted  request  from  the  server  window  and  paste  the  request  into 
the  proper  chat  window,  which  is  only  one  step  compared  to  the  three  steps  needed  by  the 

traditional  method  to  input  a  MEDEVAC  request. 
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Error  Rate  of  MEDEVAC  Request 
Submitted 

■  Without  CASEVAC  Application  ■  With  CASEVAC  Application 


Percentage 


Figure  106.  Error  Rate  of  MEDEVAC  Requests 


I.  ANALYSIS  AND  REDESIGN  AFTER  INTERMEDIATE  TESTING 

PHASE 

The  analysis  of  the  intermediate  testing  results  and  the  redesign  implemented 
based  off  of  observation  and  user  feedback  are  discussed  below. 

1,  Analysis 

The  test  results  from  the  Immediate  Test  prove  that  the  CASEVAC  application  is 
a  good  alternative  to  the  traditional  methods  of  submitting  a  MEDEVAC  requests.  We 
continued  to  have  above  a  rating  of  4.6  out  of  a  maximum  of  5.0  in  all  categories  for 
Survey  1 ,  which  has  been  maintained  since  the  beginning  of  testing  because  of  the  many 
redesigns  of  our  layout  and  flow  of  the  application  suggested  by  users.  The  testing 
showed  a  decrease  of  20%,  19.5  seconds,  in  the  amount  of  time  needed  to  submit  a 
request  using  the  CASEVAC  application  from  the  last  round  of  testing,  even  though  the 
experience  level  with  MEDEVAC  procedure  was  lower  than  the  round  before.  This 
dramatic  reduction  in  time  again  validates  the  major  redesign  of  the  application. 
Additionally,  the  total  number  of  clicks  went  from  35  down  to  24,  which  is  a  reduction  of 
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30%.  This  round  of  test  not  only  showed  that  users  submitted  their  request  faster  than  in 
earlier  test  rounds,  but  that  the  users  using  the  CASEVAC  application  could  generate  and 
submit  a  request  an  average  of  two  minutes  faster,  with  less  errors,  than  their  peers  using 
traditional  methods  to  submit  a  MEDEVAC  request.  This  increase  in  speed  and  accuracy 
gives  the  patient  precious  time  that  can  be  utilized  by  evacuation  units  and  medical 
personnel  to  deliver  key  medical  treatment  to  the  patient  within  the  “Golden  Hour.” 
Overall,  the  test  results  for  Intermediate  Testing  Phase  were  positive  and  we  feel  based 
on  the  feedback  received  during  this  phase  that  we  could  move  onto  the  Eield  Testing 
Phase  after  making  minor  adjustments  to  the  CASEVAC  application  that  were  mentioned 
in  Survey  2. 

2.  Additional  Improvements  to  implement  based  off  Intermediate 
Testing 

The  improvements  outlined  in  the  following  subsections  would  have  been  made  if 
time  permitted  based  off  of  observation  and  user  feedback. 

a.  Highlighting  Key  Button  and  Changes 

We  would  do  more  to  make  key  buttons  in  the  application  more  prominent  to  the 
user.  Example  buttons  would  be  the  “Click  to  Use  Device  GPS”  button  and  the  “Click  to 
Use  Preset”  button  located  respectively  on  screens  2  and  3.  Most  likely  we  would  not 
only  increase  the  size  of  the  buttons  but  make  the  buttons  a  different  color  as  well  or  find 
another  means  in  which  to  make  them  standout  more  on  the  screen.  Next,  we  would 
explore  means  in  which  to  draw  the  user’s  attention  to  the  bottom  part  of  the  screen  when 
the  line  at  the  bottom  changes  from  red  to  green  or  vice  versa.  This  could  be 
accomplished  with  a  combination  of  methods,  which  include  increasing  the  size  of  the 
line  or  making  the  line  flash  for  a  period  of  time. 

b.  Helpful  Definitions  Improvements 

The  amount  of  positive  feedback  that  the  users  expressed  about  the  definition  of 
key  terms  within  the  application  prove  to  us  that  they  are  needed  and  extremely  helpful. 
However,  we  did  receive  some  negative  feedback  that  signals  that  we  can  improve  on  the 
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delivery  on  this  information.  The  first  improvement  is  to  find  a  better  method  of 
informing  the  user  that  there  are  helpful  hints  within  the  application.  This  could  be 
accomplished  by  making  words  with  helpful  hints  different  colors  or  adding  a  ‘?’  to  the 
corner  of  every  word.  The  second  improvement  is  to  reduce  the  chance  of  a  user 
accidently  selecting  the  helpful  hint  box.  This  could  be  done  by  adjusting  the  target  area 
in  which  the  user  needs  to  press  to  trigger  the  hint  box,  but  we  need  to  be  careful  not  to 
make  the  target  area  too  small  that  way  the  user  can  still  easily  select  the  hint  when 
needed.  The  last  improvement  that  needs  to  be  made  is  to  make  the  helpful  hint  box 
easier  to  close,  whether  it  is  opened  on  purpose  or  accident.  Currently,  one  can  only  close 
the  box  by  pressing  the  ‘X’  in  the  upper  left-hand  corner.  The  size  of  the  ‘X’  needs  to  be 
increased  or  a  different  type  of  helpful  hint  box  with  a  larger  surface  area  to  close  the  box 
needs  to  be  used. 

J.  CHAPTER  SUMMARY 

Our  tests  were  positive  and  proved  that  the  CASEVAC  application  could  be  a 
viable  option  in  submitting  a  MEDEVAC  request  on  the  battlefield.  The  tests  prove  that 
an  untrained  user  with  little  to  no  training  on  the  application  or  MEDEVAC  procedures 
can  submit  a  request  faster  and  more  quickly  and  accurately  than  a  peer  with  similar 
training.  Eurthermore,  the  testing  proves  the  military  does  not  need  the  most 
technologically  advanced  smartphones  to  achieve  these  types  of  results,  and  shows  what 
could  be  achieved  if  smartphones  were  available  to  both  trained  and  untrained  individuals 
on  the  battlefield. 
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V.  CONCLUSIONS 


A.  HYPOTHESIS  TEST  RESULTS 

Throughout  our  application  testing,  it  became  very  clear  that  our  hypothesis 
presented  in  chapter  1  was  confirmed.  The  entry  level  Marines,  with  little  to  no  prior 
training,  performed  in  a  superior  manner  when  using  HELP.  Those  using  the  application 
took,  on  average,  approximately  half  of  the  time  to  finalize  the  request  and  made 
approximately  half  of  the  errors  versus  those  who  used  traditional  pen-and-paper  means. 

B,  SECONDARY  RESEARCH  QUESTION  RESULTS 

1,  Which  sensing  modalities  of  current  COTS  mobile  devices  can  he 
used  to  facilitate  rapid  request  generation? 

The  primary  sensing  modality  that  we  employed  was  the  GPS.  Simply  being  able 
to  click  a  button  to  display  the  current  location,  results  in  a  huge  time  savings  over 
traditional  means. 

2,  What  measures  can  he  taken  to  prevent  errors  in  the  generation  of 
call  for  resources? 

A  simple  user  interface  is  the  key  to  error  prevention.  We  feel  that  breaking 
information  down  to  manageable  chunks  assists  users  by  making  it  easier  for  them  to 
manage  the  complexity  of  the  process.  The  user  is  able  to  focus  on  the  required  input  for 
a  single  line  and  move  on  when  ready. 

Additionally,  digital  communication  capability  greatly  reduces  the  number  of 
errors  by  eliminating  the  inherent  difficulties  of  transmitting  large  amounts  of  complex 
information  over  a  voice  radio. 

3,  What  measures  can  he  taken  to  make  the  application  usahle  in 
stressful  environments? 
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Our  users  told  us  that  haptic  feedback  was  critical  to  error  prevention.  Both  the 
built-in  vibration  capability  and  simple  color-changing  techniques  benefits  the  user  by 
indicating  when  something  has  changed. 

4.  What  are  the  time  and  accuracy  benefits  to  using  a  handheld  device 
compared  with  traditional  methods? 

Users  of  our  application  completed  a  simple  CASEVAC  scenario  in  50%  of  the 
time  and  with  50%  of  the  errors  when  compared  with  a  manual  group.  The  average 
amount  of  saved  time  was  approximately  two  minutes,  without  factoring  in  voice 
transmission  time. 

5.  Can  an  untrained  Marine  or  Soldier  use  the  device  with  little  or  no 
prior  training? 

The  answer  to  this  question  is  a  resounding  “Yes.”  With  only  a  few  minutes  of 
introduction  on  the  device,  entry  level  Marines  were  able  to  successfully  use  our 
application. 

6.  What  are  the  security  concerns  when  dealing  with  individual  mohile 
devices? 

Security  will  always  be  a  concern  when  using  any  digital  device  communication 
device.  However,  as  the  transmission  of  the  request  is  a  simple  string  array,  the 
technology  already  exists  to  provide  secure  transmission.  Data  at  rest  is  another  issue,  but 
that  is  beyond  the  scope  of  our  thesis. 

C.  PLATFORM 

HELP  was  tested  on  a  smartphone  that  would  be  considered  out-of-date  when 
compared  against  the  state-of-the-art  devices  and  certainly  not  designed  to  handle  the 
rigors  of  military  use  and  extreme  conditions.  So  before  any  field-testing  began,  we 
carefully  considered  which  type  of  device  or  devices  the  HELP  suite  would  be  deployed 
on  in  the  military.  We  do  not  recommend  any  particular  device  or  devices  because  new 
ruggedized  devices  are  being  released  at  a  fairly  regular  rate  ranging  in  price  from  $500- 
$1000,  and  any  recommended  device  would  most  likely  be  out  of  date  by  the  time  action 
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is  taken  to  test  the  deviee  or  deviees.  However,  some  obvious  features  that  would  be 
needed  in  the  device  before  it  is  adopted  for  use  are  listed  below: 

•  Able  to  run  Android  Operating  System 

•  Waterproof 

•  Long  battery  life  and  replaceable  battery 

•  User  friendly  interface 

•  Easy  to  upgrade 

•  Ruggedized  to  military  standard 

Another  route  to  explore  instead  of  a  ruggedized  smartphone  is  the  development 
of  a  case  to  protect  a  non-ruggedized  device,  which  would  allow  the  device  to  be  used 
under  military  conditions.  This  option,  if  feasible,  would  give  the  military  more  options 
in  COTS  devices  from  which  to  select.  Finally,  the  military  could  always  have  a  company 
build  a  device  especially  for  the  military,  but  this  option  would  be  by  far  the  most  costly. 

D,  FUTURE  WORK 

This  section  discusses  future  work  that  needs  to  be  conducted  to  further  evaluate 
HELP  as  an  application  that  could  be  used  in  a  combat  environment. 

1,  Field  Testing 

Future  testing  needs  to  be  conducted  in  a  field  environment  to  properly  evaluate 

HELP  for  future  use. 

a.  Recommended  Venue 

Unfortunately,  because  of  several  constraints,  we  were  not  able  to  conduct  any 
field  testing.  While  initial  and  intermediate  testing  phases’  results  were  positive,  field 
testing  needs  to  be  done  to  verify  the  application  can  properly  be  utilized  on  the 
battlefield  by  users  of  all  experience  levels  and  under  all  environmental  conditions.  There 
will  need  to  be  several  rounds  of  field  testing  before  the  application  will  be  ready  for 
deployment  to  the  operating  forces;  however,  the  best  place  to  start  this  testing  would  be 
the  Infantry  Immense  Trainer  (IIT).  There  are  three  IITs  located  in  the  Marine  Corps.  The 
IIT  is  a  facility  that  simulates  a  combat  environment  in  all  aspects  from  sights  and  sounds 
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to  simulated  casualties.  The  IIT  would  be  ideal  for  initial  field  testing  because  the  facility 
can  control  numerous  variables  and  the  facility  numerous  cameras  that  can  be  leveraged 
to  observe  the  user  of  the  application  from  many  different  angles  in  the  compound.  With 
the  initial  field  testing  done  at  an  IIT  the  evaluation  of  the  results  would  be  easier  because 
of  the  facility’s  ability  to  control  variables. 

2.  Security 

During  the  development  of  our  applications  security  was  not  the  primary  concern. 
While  we  knew  security  was  important,  our  efforts  were  focused  on  proving  that  a 
smartphone  application  could  be  used  by  untrained  users  to  submit  a  request  in  a  stressful 
environment.  Now  that  we  proved  that  it’s  possible,  attention  needs  to  be  given  to  the 
applications’  security. 

a.  Data  at  Rest 

When  the  HELP  application  is  opened  it  creates  a  database  that  is  used  to  store 
information  about  the  user’s  unit  and  higher  headquarter.  The  database  is  then  referenced 
by  the  other  three  applications  to  retrieve  this  information  to  speed  up  the  construction  of 
the  request.  This  database  on  the  phone  could  be  exploited  by  unauthorized  users  if  the 
phone  were  to  find  its  way  into  unfriendly  hands  or  be  hacked.  Work  needs  to  be  done  to 
find  the  best  method  to  secure  the  database  from  unauthorized  users  while  the  phone  is  at 
rest.  This  could  be  as  simple  as  encrypting  the  database  to  a  more  complex  security 
protocols.  Whatever  method  is  used,  one  must  consider  the  effects  that  the  security 
measures  will  have  on  the  performance  of  the  applications  and  its  ability  to  access  the 
information  in  the  database  quick  and  efficiently. 

b.  Data  During  Transmission 

To  transmit  the  request  from  the  phone  to  the  server  we  used  the  Wave  Relay 
Radio  to  establish  a  Wi-Fi  hotspot  which  the  phone  uses  to  push  the  request  to  the  server. 
The  access  point  uses  WPA2  to  encrypt  the  request  as  it  moves  from  the  smartphone  to 
the  Wi-Fi  hotspot.  WPA2  requires  a  password  to  gain  access  to  the  access  point  and  is 
used  by  many  businesses  and  government  agencies  to  secure  their  wireless  traffic. 


152 


However,  analysis  needs  to  be  eonducted  to  determine  if  WPA2  meets  the  security 
requirements  for  the  military  for  the  information  that  is  being  transmitted  by  the  requests. 
We  expect  that  WPA2  will  not  meet  the  military’s  security  requirements  so  research 
needs  to  be  conducted  on  what  is  the  best  method  to  secure  the  requests  during 
transmission  but  not  create  too  much  overhead,  so  the  security  measures  do  not  become  a 
burden  of  the  user  or  the  bandwidth  available. 

c.  Two-  Way  A  uthentication 

Currently  the  application  submits  the  request  to  the  server  and  there  is  no 
authentication  done  by  the  application  or  the  server  to  prove  a  device’s  identification  or  if 
the  device  has  permission  to  submit  or  receive  the  request.  This  arrangement  between  the 
application  and  the  server  would  not  work  in  the  realistic  military  settings  as  unfriendly 
users  could,  with  some  effort,  spoof  the  application  or  the  server.  This  could  lead  to  fake 
requests  being  submitted  or  false  acknowledgments  sent  to  the  application,  and  one  can 
imagine  the  many  issues  this  would  cause. 

Research  needs  to  be  conducted  to  determine  the  best  method  for  mutual 
authentication  between  the  application  and  the  server.  Many  organizations  in  the 
government  and  the  private  sector  have  protocols  they  use  for  their  mobile  application 
that  already  solve  this  challenge.  The  issue  would  be  to  find  the  protocol  that  meets  the 
military’s’  requirements  while  at  the  same  time  as  not  creating  an  undue  burden  on  the 
application  or  the  server. 

3.  Additional  Features 

Many  additional  features  were  suggested  by  the  users  who  tested  the  application, 
and  we  thought  of  several  others  as  we  went  through  the  development  of  the  applications. 
Below  is  a  list  of  the  top  seven  features  to  add  that  we  did  not  get  the  chance  to 
implement  because  of  time  or  coding  experience  constraints. 

a.  Z-MIST  Report 

The  CASEVAC  application  currently  only  submits  the  standard  NATO 
MEDEVAC  request  and  not  the  follow-on  Z-MIST  Report.  Z-MIST  stands  for  Zap 
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number  and  blood  type,  Meehanism  of  injury,  Injury  sustained.  Signs  and  system. 
Treatment  given.  The  Zap  number  is  a  number  given  to  military  personnel  by  their  unit  to 
identify  them  over  the  radio  without  having  to  say  their  aetual  name.  The  Z-MIST  report 
is  used  to  give  the  higher  headquarters  and  the  medieal  personnel  better  situational 
awareness.  The  report  identifies  the  aetual  individual  injured  and  more  importantly  the 
extent  of  the  patient’s  injuries.  The  Z-MIST  report  is  or  was  used  in  Iraq  and  Afghanistan 
and  is  sent  immediately  following  the  standard  NATO  MEDEVAC  request.  The 
CASEVAC  applieation  eould  be  modified  so  that  after  the  user  submits  the  MEDEVAC 
request  the  applieation  would  take  the  user  to  a  different  sereen  to  start  the  generation  of 
the  Z-MIST  report  for  eaeh  patient.  The  flow  of  the  applieation  to  eomplete  the  Z-MIST 
report  should  be  similar  to  the  flow  used  to  enter  the  standard  MEDEVAC  request,  and 
should  dynamically  create  the  proper  number  of  Z-MIST  reports  based  on  the 
information  entered  earlier  by  the  user. 

b.  QR  Code 

Quick  Reader  Code  or  QR  Code,  which  is  its  more  popular  name,  is  a  matrix  type 
barcode  that  has  seen  widespread  use  in  numerous  industries.  Currently  businesses  are 
using  QR  Codes  on  advertisements  to  provide  individuals  with  additional  information  or 
a  link  to  a  website  by  scanning  the  QR  code  located  on  the  advertisement  with  a  QR  code 
reader  [37].  QR  Codes  are  easy  to  make  and  can  store  up  to  nearly  3000  text  characters 
[38].  Today’s  smartphones  can  easily  support  a  third  party  QR  code  reader  application 
and  some  smartphones  are  now  even  being  released  with  native  QR  code  readers. 

The  use  of  the  QR  code  for  the  CASEVAC  or  Rapid  Request  applications  would 
greatly  increase  the  speed  and  efficiency  of  the  user.  Take  the  implementation  of  the  QR 
code  reader  in  the  CASEVAC  application  as  a  prime  example  if  the  Z-MIST  report  was 
added  to  the  application.  All  individuals  deploying  to  a  combat  zone  get  issued  at  least 
three  identical  laminated  small  pieces  of  paper  that  contain  their  zap  number,  blood  type, 
allergies,  and  serialized  gear  assigned  to  them.  These  pieces  of  paper  are  referred  to  a  zap 
or  kill  cards  by  service  members,  and  they  are  placed  one  in  an  upper  uniform  pocket, 
one  in  a  lower  uniform  pocket,  and  the  last  in  their  medical  kit.  If  a  service  member  is 
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injured  the  zap  eards  are  used  to  give  the  person  requesting  the  MEDEVAC  key 
information  needed  to  complete  the  Z-MIST  report. 

QR  codes  could  be  leveraged  to  speed  up  the  generation  of  the  Z-MIST  report  by 
adding  a  QR  code  to  the  zap  cards,  with  the  patient’s  information  needed  in  the  Z-MIST 
report  stored  in  the  QR  cods  (Eigure  107).  Next  a  QR  code  reader  could  be  easily 
implemented  into  the  CASEVAC  application,  which  would  allow  the  application  to  read 
the  QR  code  on  the  zap  card  and  automatically  populate  several  fields  within  the  Z-MIST 
report.  QR  codes  could  be  leveraged  for  the  Rapid  Request  application  by  adding  QR 
codes  to  military  supplies  so  all  an  individual  has  to  do  is  scan  the  code  on  the  item  and 
input  the  quality  that  they  want,  instead  of  manually  entering  in  the  item. 


Major  Ryan  o+ 

Barnes 
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Eigure  107.  Sample  QR  Code  Example 
c.  Historical  Entries 

There  are  several  locations  in  all  the  applications  where  the  user  is  required  or  has 
the  option  of  manually  entering  information  for  a  particular  field  via  the  keyboard.  To 
increase  the  speed  and  efficiency  of  the  user,  the  applications  should  store  pervious 
entries  and  allow  the  user  to  access  those  entries  when  typing  in  that  particular  field.  We 
envision  a  drop  down  like  menu  that  dynamically  changes  based  on  previous  inputs  from 
the  user.  This  menu  would  appear  when  the  user  is  typing  in  a  field  and  allow  the  user  to 
select  from  a  previous  list  of  inputs  for  that  particular  field  only.  This  would  help  reduce 
the  time  and  error  rate  when  generating  a  request.  Below  is  a  picture  similar  to  what  we 
envision. 
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9:59  PM  1 

AutoCampleteDemo 

Please  type  in  a  country  name. 

Country : 

India 

Indonesia 

Figure  108.  Historical  Entry  Example,  from  [39] 

d.  Form  Reset 

None  of  the  applications  that  we  created  have  the  ability  to  reset  all  fields  within 
the  applications  without  closing  down  the  application  completely,  and  we  realize  this 
could  be  an  issue  in  the  future.  To  correct  this,  there  needs  to  be  away  for  the  user  to 
completely  reset  all  the  fields  within  the  application  quickly.  This  feature  needs  to  be 
easily  accessible  but  not  too  accessible  so  that  the  user  could  accidently  reset  the  request 
unknowingly.  We  believe  that  the  best  place  for  this  feature  is  in  the  drop  down  menu 
located  in  the  top  right-hand  corner  of  every  application.  The  location  of  the  form  reset 
option  here  gives  the  user  the  ability  to  access  it  from  any  screen  within  the  applications, 
and  being  located  in  the  drop  down  menu  protects  it  for  accidently  being  selected. 
However,  in  case  the  button  is  accidently  selected  the  users  should  be  required  to  verily 
they  want  to  reset  the  form  before  it  is  actually  reset. 

e.  Real  Time  Request  Status 

The  applications  currently  within  the  HELP  suite  only  receive  feedback  from  the 
server  when  the  server  has  successfully  received  the  respective  request.  A  feature  to 
improve  the  communication  between  the  application  and  the  server  is  to  allow  the  server 

to  send  messages  to  the  application  about  the  status  of  the  request  and  the  application  has 
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the  ability  to  respond  to  those  messages.  This  added  feature  would  operate  very  similar  to 
text  messages.  This  feature  would  give  users  of  the  applieations  and  the  server  operators 
the  ability  to  elarify  information  or  pass  updates  to  a  request  without  ever  having  to  get 
on  the  radio,  whieh  is  important  for  two  reasons.  First,  the  user  that  is  sending  the  request 
may  not  have  aeeess  to  a  radio.  Seeondly,  it  will  help  eliminate  administrative  traffie  over 
the  radio,  espeeially  when  it  eomes  to  dealing  with  the  “Rapid  Request”  applieation.  Just 
like  all  added  features,  eare  must  be  taken  to  ensure  that  the  applieations  do  not  beeome 
too  eomplex  so  it  will  not  impede  the  user’s  ability  to  quiekly  and  effieiently  submit  a 
request  in  a  battlefield  situation. 

4,  GUI  Server 

There  is  a  lot  of  future  work  that  ean  be  done  on  the  server  to  allow  HELP  to  be 
better  utilized  in  a  eombat  environment.  The  following  seetions  offer  a  list  of  upgrades 
that  needs  to  be  aecomplished. 

a.  Upgrade  from  Simple  Console 

The  server  that  we  developed  for  this  thesis  is  basie  and  is  run  from  a  eommand 
line.  While,  this  simple  server  worked  well  during  the  development  of  the  applications 
and  in  testing,  it  is  not  user  friendly  or  robust  enough  to  be  used  by  the  average  computer 
user.  Time  needs  to  be  spent  developing  a  Graphical  User  Interface  (GUI)  server  that  is 
capable  of  being  used  by  the  average  service  member  with  little  training.  The  layout  of 
the  GUI  should  mirror  any  number  to  GUI  servers  that  are  currently  on  the  market  or 
open  source,  but  be  modified  to  meet  the  military’s  requirements.  An  example  of  this  is 
the  GUI  server  should  have  a  tab  for  each  request  it  could  possibly  receive,  and  a  way  to 
alert  the  operator  that  a  request  has  been  submitted  without  having  the  user  constantly 
watching  the  screen.  Time  should  be  spent  on  determining  the  best  design  and  features  to 
add  to  the  GUI,  because  no  matter  how  quick  the  individual  in  the  field  submits  the 
request,  an  individual  at  high  headquarters  must  take  that  request  and  send  it  to  the 
appropriate  units  in  a  quick  and  efficient  manner  as  well. 
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b.  Request  Tracking 

Due  to  the  eomplex  nature  of  many  of  the  requests  that  ean  be  submitted,  there 
should  be  a  means  in  whieh  that  request  ean  be  traeked  to  ensure  the  request  are  being 
fulfilled  in  a  timely  manner  and  to  eliminate  redundant  requests.  Requests  should  be 
easily  submitted  into  a  traeker  program  that  allows  the  status  or  updates  to  the  request  to 
be  modified  with  a  simple  cliek  of  a  button.  In  addition,  to  traeking  the  current  status  of  a 
request,  the  request  tracker  program  could  also  serve  as  a  central  point  for  data  mining  to 
provide  information  on  a  number  of  topics  from  consumption  rates  for  individual  units  to 
the  response  time  for  medical  requests. 

c.  Integration  with  Tactical  Chat  Programs 

The  best  GUI  server  created  for  the  HELP  suite  is  still  very  limited  if  the  GUI 
server  does  not  have  the  ability  to  interact  with  the  current  and  future  tactical  chat 
programs.  A  properly  formatted  request  should  be  transferred  into  the  proper  tactical  chat 
window  to  get  the  request  fulfilled  and  to  eliminate  the  opportunity  for  human  error  as 
much  as  possible.  The  transfer  of  the  request  could  range  from  cutting  and  pasting  the 
request  into  the  tactical  chat  window  or  one  could  develop  a  button  so  the  operator  just 
has  to  push  a  button  to  send  the  request  to  the  correct  tactical  chat  window.  In  either  case, 
proper  forethought  must  be  given  in  the  development  of  this  feature  to  ensure  it  is  as 
simple  as  possible  to  warrant  the  implementation  of  the  HELP  suite. 

5,  Training 

Some  minor  work  will  need  to  be  accomplished  in  order  to  introduce  the  system 
into  the  operating  forces. 

a.  Training  and  Readiness  Manual  Entry 

Before  any  software  is  deployed  across  the  military  a  training  program  needs  to 
be  created  to  ensure  individuals  know  how  to  properly  use  the  software  and  know  how  to 
evaluate  and  train  individuals  on  the  software.  One  of  the  steps  in  this  process  is  to 
develop  a  new  training  and  readiness  (T&R)  standard  in  order  to  determine  under  what 
conditions  individuals  will  be  required  to  use  the  respective  application,  what  must 
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accomplish,  and  in  what  timeframe.  If  a  proper  T&R  task  is  not  inserted  into  the 
appropriate  manual  units  will  not  be  likely  to  train  on  the  applieation  they  are  given.  The 
insertion  of  a  T&R  task  sends  the  signal  that  training  on  the  applieation  is  important  and 
should  be  taken  seriously. 

b.  Evaluation  Version 

If  the  HELP  suite  is  adopted  as  a  program  of  reeord,  there  would  be  a  need  to 
develop  two  versions  of  the  eaeh  applieation;  training  and  operational.  The  differenee 
between  the  two  versions  will  be  minor  but  the  one  used  for  training  would  provide  the 
evaluators  with  more  information  than  just  the  request.  The  training  applieation  eould 
reeord  a  number  of  things  for  the  evaluators  from  the  total  time  to  eomplete  the  request  to 
the  total  number  of  elieks.  The  type  of  information  that  eould  be  reeorded  is  vast  but  the 
Program  Manager  would  ultimately  make  the  deeision  on  what  exaetly  the  training 
version  would  be  required  to  eapture  for  the  evaluators. 
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APPENDIX 


A,  SCENARIO 

Setting  up  the  HELP  Applieation 

Please  ensure  the  following  information  is  entered  into  the  HELP  Setting  Applieation 
(Replace  “X”  with  number  given  to  you  by  the  evaluator) 

-Unit:  User  “X” 

-Net  ID:  P456 
-Callsign:  User  “X” 

-Higher  HQ  IP  Address:  192. 168. 1 13.127 
-Higher  HQ  Port:  4445 

Use  the  test  connection  button  to  ensure  you  can  connect  to  the  COC 

Once  test  connection  is  successful  we  the  HELP  application  please  wait  for  instructions 
from  the  evaluators 


Operational  Scenario  for  the  CASEVAC  Application 

You  are  a  linguist  attached  to  an  Infantry  platoon  that  is  on  a  combined  daytime 
foot  patrol  with  the  Afghan  Army.  Because  of  your  language  skills,  you  are  required  to 
stay  in  the  general  vicinity  of  the  platoon  commander  at  all  times.  The  mission  of  the 
patrol  is  to  make  contact  with  the  village  elders,  and  talk  about  the  possibility  of 
establishing  a  local  police  force  in  the  village  that  is  located  10  km  from  your  patrol  base. 

The  patrol  makes  contact  with  the  village  elders  and  the  meeting  goes  well.  On 
the  way  back  to  base  one  of  the  members  of  the  lead  squad  steps  on  an  lED.  As  the 
platoon  commander  goes  forward  to  check  on  the  situation  the  enemy  opens  up  fire  from 
a  tree  line  about  200  meters  to  the  East  of  the  patrol. 

The  platoon  commander  immediately  starts  shouting  commands  to  his  squad 
leaders  via  voice  and  radio.  After  about  30  seconds  the  enemy  fire  starts  to  die  down  and 
reports  start  to  come  in  from  the  squad  leaders. 

1st  squad  reports  no  additional  casualties.  The  Marine  that  stepped  on  the  lED  has 
lost  his  leg,  but  a  tourniquet  is  controlling  the  bleeding. 

2nd  squad  reports  1  casualty,  an  Afghan  soldier  with  a  gunshot  to  the  arm. 
Bleeding  is  being  controlled  by  a  pressure  bandage  and  he  is  able  to  walk  under  his  own 
power. 
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3rd  squad  reports  2  additional  casualties. 

The  first  casualty  is  the  platoon  sergeant,  who  has  suffered  gunshot  wounds  (one 
each)  to  the  stomach  and  leg  and  is  currently  unconscious. 

The  second  casualty,  a  Marine,  has  taken  small  bullet  fragments  to  the  arm  from  a 
bullet  that  ricocheted  off  a  nearby  wall.  The  individual  is  still  able  to  move  his  arm  and 
return  fire. 

Since  the  enemy  is  still  in  the  vicinity  and  shooting  at  the  platoon  with  a  moderate 
volume  of  fire,  the  platoon  commander  doesn’t  want  to  take  himself  or  a  squad  leader  out 
of  the  fight  to  call  in  the  MEDEVAC.  The  Eieutenant  quickly  tasks  you  with  requesting 
the  MEDEVAC  for  the  four  wounded  individuals;  there  is  a  clearing  directly  south  that  is 
capable  of  supporting  a  rotary-winged  platform  landing. 


Your  mission  is  to  submit  a  complete  MEDEVAC  9-Eine  for  the  4  wounded  individuals 
as  quickly  as  possible.  A  complete  MEDEVAC  9-Eine  is  one  with  all  9  lines  filled  out. 


Scenario  Reminders/ Available  Resources: 

-The  enemy  is  still  firing  at  the  patrol. 

-You  have  a  GPS  available.  Ask  the  evaluator  at  any  point  to  receive  your  location. 

-The  patrol  has  plenty  of  smoke  and  air  panels  for  marking  the  landing  zone. 

-There  is  a  clearing  just  south  of  your  position  capable  of  supporting  a  rotary  wing 
landing. 

-There  is  no  apparent  NBC/CBRN  Contamination. 

Casualty  Info: 

-One  U.S.  Marine  that  has  lost  his  leg  below  the  knee  from  an  lED  and  is  currently 
conscious 

-One  Afghan  soldier  has  a  gunshot  wound  to  the  arm  and  the  bleeding  is  being  controlled 
by  a  pressure  dressing.  He  is  currently  conscious  and  alert. 

-One  U.S.  Marine  with  gunshot  wounds  to  the  stomach  and  leg  that  is  currently 
unconscious. 

-One  U.S.  Marine  with  bullet  fragments  to  the  arm  that  is  conscious  and  still  returning 
fire  against  the  enemy. 


B,  CASEVAC  CHEAT  SHEET 

CASEVAC  CHEATSHEET 

Eine  1.  Eocation  of  the  pick-up  site  (EAT/EONG  or  MGRS). 
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Line  2.  Radio  frequency,  call  sign,  and  suffix. 

Line  3.  Number  of  patients  by  precedence: 

A-Urgent 
B-Urgent  Surgical 
C-Priority 
D-Routine 
E-Convenience 

Line  4.  Special  equipment  required: 

A-None 

B-Hoist 

C-Extraction  equipment 
D- Ventilator 

Eine  5.  Number  of  patients: 

E-Eitter 
A-  Ambulatory 

Eine  6.  Security  at  pick-up  site: 

N-No  enemy  troops  in  area 

P-Possible  enemy  troops  in  area  (approach  with  caution) 
E-Enemy  troops  in  area  (approach  with  caution) 
X-Enemy  troops  in  area  (armed  escort  required) 

Eine  7.  Method  of  marking  pick-up  site: 

A-Panels 

B-Pyrotechnic  signal 
C-Smoke  signal 
D-None 
E-Other 

Eine  8.  Patient  nationality  and  status: 

A-U.S.  Military 
B-U.S.  Civilian 
C-Non-U.S.  Military 
D-Non-U.S.  Civilian 
E-EPW 

Eine  9.  NBC  Contamination: 

N-Nuclear 

B-Biological 

C-Chemical 
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c. 


SURVEY  1  “USERS  OF  THE  CASEVAC  APPLICATION” 


Survey  for  CASEVAC  Application-version  number  1 
Date  (DDMMMYY): _ 

User  # _ 

1.  What  is  your  Service  and  current  rank  and  pay  grade  (ex:  USMC  Sgt  E-5)? 

2.  What  is  your  age? 

3.  How  long  have  you  been  in  the  military? 

4.  What  is  your  MOS  or  Rate  with  a  description  (ex:  0302  Infantry  Officer)? 

5.  Rate  your  experience  with  9-Eme  Medical  Evacuation  procedures  on  a  scale  1-5 
(circle  one)? 

(1-  No  Experience,  2-  Informal  Training,  3-Eormal  Training,  4-Called  in  9-Eme  in 
Training,  5-Called  in  9-Eme  in  Combat  Environment) 

1  2  3  4  5 

6.  What  feature  did  you  like  the  best  and  why? 

7.  What  feature  did  you  dislike  the  most  and  why? 


8.  What  features  do  you  feel  need  to  be  added  to  the  application  that  are  not  currently 
there  and  why? 


9.  What  screen  do  you  feel  you  spent  the  most  time  on? 


10.  Which  screen,  if  any,  did  you  find  confusing  and  why? 


1 1 .  What  are  the  greatest  challenges  that  you  think  a  user  will  experience  in  using  this 
application? 

12.  Other  suggestions  or  comments? 
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D. 


SURVEY  2  “QUESTIONNAIRE” 


1  =  strongly  Disagree  2  =  Disagree  3  =  Neutral  4  =  Agree  5  =  Strongly  Agree 

Catraory 

Score 

Section  A:  G\SEVAC  appearance 

»»*»** 

1.  The  colors  for  the  application  were  appropriate 

1  2  3  4  5 

2.  The  text  was  easy  to  read 

1  2  3  4  5 

3.  The  buttons  were  easy  to  locate  and  press 

1  2  3  4  5 

4.  I  don’t  notice  any  Inconsistencies  between  the  layout  of  different  pages 

1  2  3  4  5 

Section  B:  Ease  of  use 

1.  I  always  kne\s'  what  to  do  next 

1  2  3  4  5 

2.  The  time  saving  features  were  effective 

1  2  3  4  5 

3  Important  information  was  highlighted  appropriately 

1  2  3  4  5 

4.  It  required  the  fewest  steps  possibleto  accomplish  the  mission 

1  2  3  4  5 

5.  I  could  use  the  application  Mith  litde  or  no  instructions 

1  2  3  4  5 

6.  I  always  knew  where  to  click 

1  2  3  4  5 

7.  I  never  felt  lost  during  navigation  of  this  application 

1  2  3  4  5 

8.  The  hints  were  easy  to  find 

1  2  3  4  5 

9.  The  hints  provided  were  useful  and  easy  to  understand 

1  2  3  4  5 

10.  I  never  did  something  and  got  an  unexpected  result 

1  2  3  4  5 

Section  C:  Mistakes  and  Error  Handling 

1.  Mistakes  were  not  easy  to  make 

1  2  3  4  5 

2.  I  was  immediately  aware  of  any  mistakes  1  made 

1  2  3  4  5 

3.  Recovery  from  mistakes  were  quick  and  easy 

1  2  3  4  5 

Section  D:  Overall  Impression 

1.  I  thought  various  functions  were  integrated  well  (GPS,  Pre-set) 

1  2  3  4  5 

2.  I  see  this  application  as  being  useful  to  the  military 

1  2  3  4  5 

3.  I  was  satisfied  with  the  application 

1  2  3  4  5 

Total 

/lOO 

E.  SURVEY  3  “USERS  OF  THE  TRADITIONAL  MEANS” 


Survey  for  CASEVAC  Application-version  1 
Date  (DDMMMYY); _ 

User  # _ 

1.  What  is  your  Service  and  current  rank  and  pay  grade  (ex:  USMC  Sgt  E-5)? 

2.  What  is  your  age? 

3.  How  long  have  you  been  in  the  military? 

4.  What  is  your  MOS  or  Rate  with  a  description  (ex:  0302  Infantry  Officer)? 

5.  Rate  your  experience  with  9-Line  Medical  Evacuation  procedures  on  a  scale  1-5 
(circle  one)? 
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(1-  No  Experience,  2-  Informal  Training,  3-Formal  Training,  4-Called  in  9-Line  in 
Training,  5-Called  in  9-Line  in  Combat  Environment) 

1  2  3  4  5 

Time  to  prepare  the  CASE  VAC  request- _ 

Please  write  down  how  you  would  have  transmitted  the  9-Line  to  higher  headquarters 

Line  1- _ 

Line  2- _ 

Line  3- _ 

Line  4- _ 

Line  5- _ 

Line  6- _ 

Line  7- _ 

Line  8- _ 

Line  9- _ 

F.  HIGH  VELOCITY  HUMAN  FACTORS  LAWS 

The  text  in  this  subsection  is  extracted  from  a  2007  article  by  M.  Rahman  [13]. 

1.  Law  of  Relevance 

The  human-machine  interface  (HMI)  should  aid  the  human  agent  to  sense, 
perceive  and  lock-in  on  relevant  cues  (data\information)  and  make  irrelevant  cues, 
irrelevant. 

Illustrations  for  the  first  law  of  HVHL 

A  digital  display  of  the  police  car,  when  engaged  in  a  high-speed  pursuit,  could 
morph  as  follows: 

•  The  electronic  digital  speedometer  could  [dynamically]  enlarge  in  size  and 
occupy  the  entire  display. 
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•  The  above  would  be  faeilitated  by  oceupying  the  digital  real  estate, 
previously  oceupied  by  other  digital  gauges  sueh  as  engine  temperature, 
engine  RPM,  fuel  gauge  ete.,  which  have  now  become  irrelevant  to  the 
current  context  (high  speed  pursuit). 

2,  Law  of  Acceptance  [of  Relevance] 

An  HMI  shall  not  aid  or  abet  the  agent  from  going  into  total  lock-down 
(cognitive\visual  tunneling)  at  the  expense  of  becoming  immune  to  relevant  signals  or  all 
together  missing  newly  emerging  and  relevant  cues  in  the  environment. 

Illustrations  for  the  second  law  of  HVHF 

•  An  interface  should  not  overwhelm  the  senses  and\or  cognitive  resources 
of  the  human  agent  to  the  extent  that  he  becomes  oblivious  to  the 
immediate,  personal  and  local  environment. 

•  An  interface  should  be  adaptive  to  the  context  and  workload  of  the 
human  agent.  For  example,  in  a  covert  operating  situation  (context)  and 
when  the  sniper  (human  agent)  has  locked-in  on  a  target  in  a  dynamic 
environment  (high  workload;  moving  target  in  a  crowded  field  of  innocent 
civilians),  the  interface  should  adapt  in  that  it  should  suppress  all  alerts 
that  are  neither  relevant  to  the  current  context  nor  urgent  to  the  situation 
on  hand. 

3,  Law  of  Transparence 

An  HMI  shall  not  become  a  barrier  to  information  that  could  and  should  be  sensed 
directly  from  the  immediate  environment. 

Illustrations  for  the  third  law  of  HVHF 

•  Poorly  designed  fire-fighter  helmet-hoods,  monocular  Helmet  Mounted 
Displays(HMDs)  or  night  vision  goggles  may  restrict  peripheral  vision 
and\or  introduce  binocular  rivalry  (in  the  case  of  monocular  HMDs),  and 
thus,  may  become  a  barrier  rather  than  an  aid  during  tactical  operations. 

•  Heads-up  Displays  (HuDs)  should  not  become  opaque  barriers  on  the 
windscreen  of  a  vehicle  and  occlude  information  that  could  be  gleaned 
directly  in  the  immediate  environment.  Nor  should  they  pose  visual 
challenges  (ocular  motor)  by  requiring  significant  and  rapid  changes  in 
focal  length. 
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•  Do  not  present  information  that  ean  be  sensed  and  pereeived  directly  in  the 
immediate  environment  on  the  display.  Only  relevant  information  that  is 
beyond  the  reach  and  capabilities  of  the  human  senses — in  terms  of 
sensation  threshold,  amplification  and  resolution-should  be  presented. 

4,  Law  of  Clairvoyance 

The  HMI  should  assist  the  agent  in  imagining  the  future  state  of  the  world  for  a 
given  course  of  action,  or  for  an  event  that  is  already  unfolding  in  real  time. 

Illustrations  for  the  fourth  law  of  HVHF 

•  Use  technology  to  provide  intelligence  of  various  kinds  (listed  below),  so 
that  the  agent  can  build  a  mental  model  of  the  current  situation  and  to 

predict  possible  future  states.  This  process - as  rapid  as  it  may  be - 

should  facilitate  the  agent  mentally,  simulate  the  possible  courses  of  action 
and  assist  him  in  choosing  the  most  successful  course  of  action.  Types  of 
intelligence  that  technology  should  provide  to  the  human  agent  (either  on 
demand  or  a  need  to  know  basis): 

o  On  the  scene  intelligence  (e.g.,  nature  of  conflict;  number  of 
people  involved,  their  disposition  [Hostage?  Injured?  Fugitive?], 
their  capabilities  [weapon?  medical?],  etc. 

o  Technical  intelligence  (e.g.,  satellite  imagery,  maps  &  route 
information,  scanning  sensors — for  beyond  human  sensory  range 
sensing) 

o  Tactical  intelligence  (e.g.,  number  of  officers  involved  and  their 
capabilities;  plan  of  actions  [plan  A,  B...];  intra  and  inter  agency 
command,  coordination  and  control  issues  pertaining;  use  of 
stealth — i.e.,  ability  to  suppress  one’s  own  signal  when  employing 
elements  of  surprise) 

•  Use  technology  to  predict  the  dynamics  and  future  states  of  objects  and 
people  already  in  motion.  For  example,  if  an  officer  has  requested  a  back¬ 
up — and  has  been  dispatched — the  interface  should  provide  on  the 
expected  time  of  arrival  at  the  destination;  or  in  the  event  the  officer  who 
made  the  request  is  in  motion,  then,  the  time  and  place  [in  space]  of 
intersection.  In  the  case  of  a  fleeing  target,  based  on  road  conditions, 
traffic  patterns,  etc.,  information  may  be  provided  to  the  officer  in  pursuit 
regarding  the  time  and  place  of  probable  interdiction  with  the  target. 
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•  The  above  should  not  eome  with  a  cost:  obscuring  information  that  is 
important  in  the  local,  personal  and  immediate  context. 

5.  Law  of  Absoluteness 

The  HMI  shall  provide  instant  access  to  vital  functions  that  need  to  be  accessed  in 
a  split  second  by  providing  dedicated  physical  and  tactile  controls — including  rapid 
cognition  of  relevant  information — with  a  one-to-one  mapping  to  the  specific  element 
that  it  would  control.  [13] 

•  Multi-sequence  actions  such  as  navigating  through  menus  should  be 
abhorred. 

•  In  the  operational  sense,  interactions  with  the  interface  should  neither 
require  deliberate  thought  nor  fishing  in  space,  (e.g.,  through  a  large  array 
of  controls  to  make  contact  &  locate).  That  is,  the  designer  should  harness 
the  kinesthetic  memory  of  the  human  muscular  system  and  make  it 
independent  of  visual  guidance  to  the  extent  possible. 

•  There  are  occasions  when  it  becomes  necessary  to  rapidly  comprehend 
information  with  rough  approximations  rather  than  detailed  information 
with  a  higher  precision  or  resolution.  For  example,  when  the  human  agent 
is  time  constrained,  a  bar  graph  that  shows  the  amount  of  fuel  left  (coarse 
numerical  resolution)  might  be  superior  to  reading-off  a  numerical  value 
(e.g.,  8.32  gal.)  from  a  crowded  display. 

6.  Law  of  Intelligence 

Technology  should  be  smart  and  adaptive  and  offload  the  human  based  on 
situation,  context,  and  workload  in  a  reliable  manner.  The  agent  should  be  “invited”  back 
into  the  loop  of  action  at  appropriate  moments  when  decision-making  becomes  the 
prerogative  of  human  intelligence  and  not  that  of  technology. 

Corollary: 

The  human  agent  should  be  able  to  override  functions  allocated  to  technology  or 
override  decisions  made  by  it  at  any  time  and  at  a  moment’s  notice  (see  Fifth  Law  on  The 
Law  of  Absoluteness). 

Illustrations  for  the  sixth  law  of  HVHF 

•  The  adaptive  cruise  control  in  automobiles — the  use  of  forward-looking 
RADAR  to  monitor  the  speed  and  distance  of  the  vehicle  in  front — to 
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maintain  a  safe  distance  is  an  example  of  technology  alleviating  the 
human  agent’s  workload. 

•  If  a  police  vehicle  has  to  enter  a  “stealth”  zone  (not  reveal  itself) — say,  to 
interdict  a  hostage  taker  through  the  “surprise” — after  speeding  through 
traffic,  the  sirens  and\or  lights  could  be  turned  off. 

7,  The  Law  of  Reliance 

A  solution,  system  or  technology  should  be  trustworthy  and  reliable  almost  to  the 
point  of  being  treated  with  reverence. 

Illustrations  for  the  seventh  law  of  HVHF 

•  A  motion  sensor  mounted  on  a  police  car  is  unable  to  discriminate 
between  the  movement  of  a  tree  branch  and  the  approach  of  a  person, 
thereby  resulting  in  the  disabling  of  the  sensor  or  the  need  to  assess  the 
probable  value  of  a  warning. 
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